Trouble with mutex/cond destroy on WINCE 3.0

Trouble with mutex/cond destroy on WINCE 3.0

[Craig A. Vanderborgh]

Hello All:

I have just done a port of pthreads-win32 to our recently completed
arm-wince-pe GNU development environment.  This is different that what
others have been doing with pthreads-win32 in the following ways:

1. We are not using Visual C++ or EVC.  We have our own port of the GNU
toolchain (binutils-2.13.90 & gcc-3.2).
2. Except for a very few primitives from coredll.dll, we are not using
the Micro$oft runtime - we are using "newlib" instead.

The porting work that was required seemed fairly straightforward and
affected mostly only header files in the end.  Unfortunately, the result
is not entirely working yet.  In particular, mutex/condvar destruction
is always returning "16" instead of "0" (EBUSY??).  Here is an example
program that shows the problem, along with the output:

#include <pthread.h>
#include <errno.h>

main(int argc, char *argv[])
{
  int i, stat;
  pthread_mutex_t mutex;
  pthread_cond_t cond;

  pthread_win32_process_attach_np();
  pthread_win32_thread_attach_np();
  stat = pthread_mutex_init(&mutex, NULL);
  printf("pthread_mutex_init returns %d, errno %d\n", stat, errno);

  stat = pthread_cond_init(&cond, NULL);
  printf("pthread_cond_init returns %d, errno %d\n", stat, errno);

  stat = pthread_cond_destroy(&cond);
  printf("pthread_cond_destroy returns %d, errno %d\n", stat, errno);

  stat = pthread_mutex_destroy(&mutex);
  printf("pthread_mutex_destroy returns %d, errno %d\n", stat, errno);

  getchar();
}

The output is thus:
thread_mutex_init returns 0, errno 0
pthread_cond_init returns 0, errno 0
pthread_cond_destroy returns 16, errno 0
pthread_mutex_destroy returns 16, errno 0

Apparently "EBUSY" is returned when there are waiters on synchronization
objects.  Clearly that can't be the case here so there must be something
wrong with my port.  The question is - what??  Any ideas on where to
look or what to do would be vastly appreciated.

TIA,
craig vanderborgh
voxware incorporated

Re: Trouble with mutex/cond destroy on WINCE 3.0

[Ross Johnson]

Craig A. Vanderborgh wrote:

>Hello All:
>
>I have just done a port of pthreads-win32 to our recently completed
>arm-wince-pe GNU development environment.  This is different that what
>others have been doing with pthreads-win32 in the following ways:
>  
>
Hi,

It looks like EBUSY is being returned by the call to 
pthread_mutex_trylock() inside of pthread_mutex_destroy(), so I'm 
wondering if there's a problem with InterlockedCompareExchange() on 
arm-wince-pe.

What I think may be happening is this: pthread_win32_process_attach_np() 
tries to detect if InterlockedCompareExchange() is supported by the 
system. If this check fails for any reason then: on X86 systems, some 
X86 specific assembler code is  called instead, everywhere it's needed 
throughout the library via the function pointer 
ptw32_interlocked_compare_exchange; on non-X86 systems the library 
implementation of  InterlockedCompareExchange 
(ptw32_InterlockedCompareExchange()) just returns 0, which will result 
in EBUSY being returned by trylock() [for non recursive mutexes].

See:
    pthread_mutex_destroy.c
    pthread_mutex_trylock.c
    pthread_win32_attach_detach_np.c
    ptw32_InterlockedCompareExchange.c.

Questions:
What error do you get if you apply pthread_mutex_trylock() to your mutex?
Can you confirm that InterlockedCompareExchange() is supported AND being 
detected?

BTW, if it turns out that you need an ARM specific 
InterlockedCompareExchange(), then the following info may be useful:

http://www.google.com.au/search?q=cache:a3Px_EyvkM0C:lists.ximian.com/archives/public/mono-list/2002-September/002519.html+arm+InterlockedCompareExchange&hl=en&ie=UTF-8

Regards.
Ross

>1. We are not using Visual C++ or EVC.  We have our own port of the GNU
>toolchain (binutils-2.13.90 & gcc-3.2).
>2. Except for a very few primitives from coredll.dll, we are not using
>the Micro$oft runtime - we are using "newlib" instead.
>
>The porting work that was required seemed fairly straightforward and
>affected mostly only header files in the end.  Unfortunately, the result
>is not entirely working yet.  In particular, mutex/condvar destruction
>is always returning "16" instead of "0" (EBUSY??).  Here is an example
>program that shows the problem, along with the output:
>
>#include <pthread.h>
>#include <errno.h>
>
>main(int argc, char *argv[])
>{
>  int i, stat;
>  pthread_mutex_t mutex;
>  pthread_cond_t cond;
>
>  pthread_win32_process_attach_np();
>  pthread_win32_thread_attach_np();
>  stat = pthread_mutex_init(&mutex, NULL);
>  printf("pthread_mutex_init returns %d, errno %d\n", stat, errno);
>
>  stat = pthread_cond_init(&cond, NULL);
>  printf("pthread_cond_init returns %d, errno %d\n", stat, errno);
>
>  stat = pthread_cond_destroy(&cond);
>  printf("pthread_cond_destroy returns %d, errno %d\n", stat, errno);
>
>  stat = pthread_mutex_destroy(&mutex);
>  printf("pthread_mutex_destroy returns %d, errno %d\n", stat, errno);
>
>  getchar();
>}
>
>The output is thus:
>thread_mutex_init returns 0, errno 0
>pthread_cond_init returns 0, errno 0
>pthread_cond_destroy returns 16, errno 0
>pthread_mutex_destroy returns 16, errno 0
>
>Apparently "EBUSY" is returned when there are waiters on synchronization
>objects.  Clearly that can't be the case here so there must be something
>wrong with my port.  The question is - what??  Any ideas on where to
>look or what to do would be vastly appreciated.
>
>TIA,
>craig vanderborgh
>voxware incorporated
>
>
>  
>

Re: Trouble with mutex/cond destroy on WINCE 3.0

[Ross Johnson]

Hi John,

Quite so. The first attempt to detect TryEnterCriticalSection did 
overlook this, and the additional check was added later. (Eventually 
Thomas Pfaff's reworking of the mutex routines eliminated the use of 
critical sections/Win32 mutexes, using the Interlocked routines and 
semaphores instead.)

However, pthreads-win32 doesn't currently apply the additional check 
on InterlockedCompareExchange and it hasn't been a problem AFAIK, 
but there's no reason not to add it as a rule.

Ross

Bossom, John wrote:
> Hi Ross,
> 
> It might not be enough to simply test for the existence of a
> function using dynamic loading on win32... Case in point:
> Win95 did not support TryEnterCriticalSection at all, whereas
> Win98 added the method, but did not implement it (i.e. returned
> function not supported if you called it...)
> 
> 
> -----Original Message-----
> From: Ross Johnson [mailto:rpj@ise.canberra.edu.au]
> Sent: Tuesday, February 25, 2003 6:16 PM
> To: Craig A. Vanderborgh
> Cc: pthreads-win32@sources.redhat.com
> Subject: Re: Trouble with mutex/cond destroy on WINCE 3.0
> 
> 
> 
> 
> Craig A. Vanderborgh wrote:
> 
> 
>>Hello All:
>>
>>I have just done a port of pthreads-win32 to our recently completed
>>arm-wince-pe GNU development environment.  This is different that what
>>others have been doing with pthreads-win32 in the following ways:
>> 
>>
> 
> Hi,
> 
> It looks like EBUSY is being returned by the call to 
> pthread_mutex_trylock() inside of pthread_mutex_destroy(), so I'm 
> wondering if there's a problem with InterlockedCompareExchange() on 
> arm-wince-pe.
> 
> What I think may be happening is this: pthread_win32_process_attach_np() 
> tries to detect if InterlockedCompareExchange() is supported by the 
> system. If this check fails for any reason then: on X86 systems, some 
> X86 specific assembler code is  called instead, everywhere it's needed 
> throughout the library via the function pointer 
> ptw32_interlocked_compare_exchange; on non-X86 systems the library 
> implementation of  InterlockedCompareExchange 
> (ptw32_InterlockedCompareExchange()) just returns 0, which will result 
> in EBUSY being returned by trylock() [for non recursive mutexes].
> 
> See:
>     pthread_mutex_destroy.c
>     pthread_mutex_trylock.c
>     pthread_win32_attach_detach_np.c
>     ptw32_InterlockedCompareExchange.c.
> 
> Questions:
> What error do you get if you apply pthread_mutex_trylock() to your mutex?
> Can you confirm that InterlockedCompareExchange() is supported AND being 
> detected?
> 
> BTW, if it turns out that you need an ARM specific 
> InterlockedCompareExchange(), then the following info may be useful:
> 
> http://www.google.com.au/search?q=cache:a3Px_EyvkM0C:lists.ximian.com/archiv
> es/public/mono-list/2002-September/002519.html+arm+InterlockedCompareExchang
> e&hl=en&ie=UTF-8
> 
> Regards.
> Ross
> 
> 
>>1. We are not using Visual C++ or EVC.  We have our own port of the GNU
>>toolchain (binutils-2.13.90 & gcc-3.2).
>>2. Except for a very few primitives from coredll.dll, we are not using
>>the Micro$oft runtime - we are using "newlib" instead.
>>
>>The porting work that was required seemed fairly straightforward and
>>affected mostly only header files in the end.  Unfortunately, the result
>>is not entirely working yet.  In particular, mutex/condvar destruction
>>is always returning "16" instead of "0" (EBUSY??).  Here is an example
>>program that shows the problem, along with the output:
>>
>>#include <pthread.h>
>>#include <errno.h>
>>
>>main(int argc, char *argv[])
>>{
>> int i, stat;
>> pthread_mutex_t mutex;
>> pthread_cond_t cond;
>>
>> pthread_win32_process_attach_np();
>> pthread_win32_thread_attach_np();
>> stat = pthread_mutex_init(&mutex, NULL);
>> printf("pthread_mutex_init returns %d, errno %d\n", stat, errno);
>>
>> stat = pthread_cond_init(&cond, NULL);
>> printf("pthread_cond_init returns %d, errno %d\n", stat, errno);
>>
>> stat = pthread_cond_destroy(&cond);
>> printf("pthread_cond_destroy returns %d, errno %d\n", stat, errno);
>>
>> stat = pthread_mutex_destroy(&mutex);
>> printf("pthread_mutex_destroy returns %d, errno %d\n", stat, errno);
>>
>> getchar();
>>}
>>
>>The output is thus:
>>thread_mutex_init returns 0, errno 0
>>pthread_cond_init returns 0, errno 0
>>pthread_cond_destroy returns 16, errno 0
>>pthread_mutex_destroy returns 16, errno 0
>>
>>Apparently "EBUSY" is returned when there are waiters on synchronization
>>objects.  Clearly that can't be the case here so there must be something
>>wrong with my port.  The question is - what??  Any ideas on where to
>>look or what to do would be vastly appreciated.
>>
>>TIA,
>>craig vanderborgh
>>voxware incorporated
>>
>>
>> 
>>
> 
> 
> 
> This message may contain privileged and/or confidential information.  If you
> have received this e-mail in error or are not the intended recipient, you
> may not use, copy, disseminate or distribute it; do not open any
> attachments, delete it immediately from your system and notify the sender
> promptly by e-mail that you have done so.  Thank you.

RE: Trouble with mutex/cond destroy on WINCE 3.0

[Craig A. Vanderborgh]

Hello John and Ross:

First thank you for your responses.  They are much appreciated and Ross'
diagnosis is very much on the mark.  During my porting work, I had to
plumb in InterlockedCompareExchange into ptw32_ICE.c. I used the
coredll.dll (M$ runtime) library function to do this, but I made a
crucial mistake.  ICE is supposed to return the INITIAL value of 
*location (its first argument), not the final value.  This mistake is
solely responsible for the problems I was having.

Now my test programs are working perfectly, but I am still having some
problems with our application.  I do not yet know if these problems are
due/related to pthreads-win32, but I kind of doubt they are.

If it's possible I'd like to locate ARM assembler source for the
Interlocked* routines.  I am sure this would be a good thing to do from
a performance perspective.  Any ideas where I might find these?

Thank you so much for your help, we really do appreciate it!  And, if
you or anyone else would like access to our ports of GCC/newlib/pthreads
for arm-wince-pe, just let us know..

best regards,
craig vanderborgh
voxware incorporated

On Wed, 2003-02-26 at 07:31, Bossom, John wrote:
> Hi Ross,
> 
> It might not be enough to simply test for the existence of a
> function using dynamic loading on win32... Case in point:
> Win95 did not support TryEnterCriticalSection at all, whereas
> Win98 added the method, but did not implement it (i.e. returned
> function not supported if you called it...)
> 
> 
> -----Original Message-----
> From: Ross Johnson [mailto:rpj@ise.canberra.edu.au]
> Sent: Tuesday, February 25, 2003 6:16 PM
> To: Craig A. Vanderborgh
> Cc: pthreads-win32@sources.redhat.com
> Subject: Re: Trouble with mutex/cond destroy on WINCE 3.0
> 
> 
> 
> 
> Craig A. Vanderborgh wrote:
> 
> >Hello All:
> >
> >I have just done a port of pthreads-win32 to our recently completed
> >arm-wince-pe GNU development environment.  This is different that what
> >others have been doing with pthreads-win32 in the following ways:
> >  
> >
> Hi,
> 
> It looks like EBUSY is being returned by the call to 
> pthread_mutex_trylock() inside of pthread_mutex_destroy(), so I'm 
> wondering if there's a problem with InterlockedCompareExchange() on 
> arm-wince-pe.
> 
> What I think may be happening is this: pthread_win32_process_attach_np()
> 
> tries to detect if InterlockedCompareExchange() is supported by the 
> system. If this check fails for any reason then: on X86 systems, some 
> X86 specific assembler code is  called instead, everywhere it's needed 
> throughout the library via the function pointer 
> ptw32_interlocked_compare_exchange; on non-X86 systems the library 
> implementation of  InterlockedCompareExchange 
> (ptw32_InterlockedCompareExchange()) just returns 0, which will result 
> in EBUSY being returned by trylock() [for non recursive mutexes].
> 
> See:
>     pthread_mutex_destroy.c
>     pthread_mutex_trylock.c
>     pthread_win32_attach_detach_np.c
>     ptw32_InterlockedCompareExchange.c.
> 
> Questions:
> What error do you get if you apply pthread_mutex_trylock() to your
> mutex?
> Can you confirm that InterlockedCompareExchange() is supported AND being
> 
> detected?
> 
> BTW, if it turns out that you need an ARM specific 
> InterlockedCompareExchange(), then the following info may be useful:
> 
> http://www.google.com.au/search?q=cache:a3Px_EyvkM0C:lists.ximian.com/ar
> chiv
> es/public/mono-list/2002-September/002519.html+arm+InterlockedCompareExc
> hang
> e&hl=en&ie=UTF-8
> 
> Regards.
> Ross
> 
> >1. We are not using Visual C++ or EVC.  We have our own port of the GNU
> >toolchain (binutils-2.13.90 & gcc-3.2).
> >2. Except for a very few primitives from coredll.dll, we are not using
> >the Micro$oft runtime - we are using "newlib" instead.
> >
> >The porting work that was required seemed fairly straightforward and
> >affected mostly only header files in the end.  Unfortunately, the
> result
> >is not entirely working yet.  In particular, mutex/condvar destruction
> >is always returning "16" instead of "0" (EBUSY??).  Here is an example
> >program that shows the problem, along with the output:
> >
> >#include <pthread.h>
> >#include <errno.h>
> >
> >main(int argc, char *argv[])
> >{
> >  int i, stat;
> >  pthread_mutex_t mutex;
> >  pthread_cond_t cond;
> >
> >  pthread_win32_process_attach_np();
> >  pthread_win32_thread_attach_np();
> >  stat = pthread_mutex_init(&mutex, NULL);
> >  printf("pthread_mutex_init returns %d, errno %d\n", stat, errno);
> >
> >  stat = pthread_cond_init(&cond, NULL);
> >  printf("pthread_cond_init returns %d, errno %d\n", stat, errno);
> >
> >  stat = pthread_cond_destroy(&cond);
> >  printf("pthread_cond_destroy returns %d, errno %d\n", stat, errno);
> >
> >  stat = pthread_mutex_destroy(&mutex);
> >  printf("pthread_mutex_destroy returns %d, errno %d\n", stat, errno);
> >
> >  getchar();
> >}
> >
> >The output is thus:
> >thread_mutex_init returns 0, errno 0
> >pthread_cond_init returns 0, errno 0
> >pthread_cond_destroy returns 16, errno 0
> >pthread_mutex_destroy returns 16, errno 0
> >
> >Apparently "EBUSY" is returned when there are waiters on
> synchronization
> >objects.  Clearly that can't be the case here so there must be
> something
> >wrong with my port.  The question is - what??  Any ideas on where to
> >look or what to do would be vastly appreciated.
> >
> >TIA,
> >craig vanderborgh
> >voxware incorporated
> >
> >
> >  
> >
> 
> 
> This message may contain privileged and/or confidential information.  If
> you
> have received this e-mail in error or are not the intended recipient,
> you
> may not use, copy, disseminate or distribute it; do not open any
> attachments, delete it immediately from your system and notify the
> sender
> promptly by e-mail that you have done so.  Thank you.

RE: Trouble with mutex/cond destroy on WINCE 3.0

[Bossom, John]

Hi Ross,

It might not be enough to simply test for the existence of a
function using dynamic loading on win32... Case in point:
Win95 did not support TryEnterCriticalSection at all, whereas
Win98 added the method, but did not implement it (i.e. returned
function not supported if you called it...)


-----Original Message-----
From: Ross Johnson [mailto:rpj@ise.canberra.edu.au]
Sent: Tuesday, February 25, 2003 6:16 PM
To: Craig A. Vanderborgh
Cc: pthreads-win32@sources.redhat.com
Subject: Re: Trouble with mutex/cond destroy on WINCE 3.0




Craig A. Vanderborgh wrote:

>Hello All:
>
>I have just done a port of pthreads-win32 to our recently completed
>arm-wince-pe GNU development environment.  This is different that what
>others have been doing with pthreads-win32 in the following ways:
>  
>
Hi,

It looks like EBUSY is being returned by the call to 
pthread_mutex_trylock() inside of pthread_mutex_destroy(), so I'm 
wondering if there's a problem with InterlockedCompareExchange() on 
arm-wince-pe.

What I think may be happening is this: pthread_win32_process_attach_np() 
tries to detect if InterlockedCompareExchange() is supported by the 
system. If this check fails for any reason then: on X86 systems, some 
X86 specific assembler code is  called instead, everywhere it's needed 
throughout the library via the function pointer 
ptw32_interlocked_compare_exchange; on non-X86 systems the library 
implementation of  InterlockedCompareExchange 
(ptw32_InterlockedCompareExchange()) just returns 0, which will result 
in EBUSY being returned by trylock() [for non recursive mutexes].

See:
    pthread_mutex_destroy.c
    pthread_mutex_trylock.c
    pthread_win32_attach_detach_np.c
    ptw32_InterlockedCompareExchange.c.

Questions:
What error do you get if you apply pthread_mutex_trylock() to your mutex?
Can you confirm that InterlockedCompareExchange() is supported AND being 
detected?

BTW, if it turns out that you need an ARM specific 
InterlockedCompareExchange(), then the following info may be useful:

http://www.google.com.au/search?q=cache:a3Px_EyvkM0C:lists.ximian.com/archiv
es/public/mono-list/2002-September/002519.html+arm+InterlockedCompareExchang
e&hl=en&ie=UTF-8

Regards.
Ross

>1. We are not using Visual C++ or EVC.  We have our own port of the GNU
>toolchain (binutils-2.13.90 & gcc-3.2).
>2. Except for a very few primitives from coredll.dll, we are not using
>the Micro$oft runtime - we are using "newlib" instead.
>
>The porting work that was required seemed fairly straightforward and
>affected mostly only header files in the end.  Unfortunately, the result
>is not entirely working yet.  In particular, mutex/condvar destruction
>is always returning "16" instead of "0" (EBUSY??).  Here is an example
>program that shows the problem, along with the output:
>
>#include <pthread.h>
>#include <errno.h>
>
>main(int argc, char *argv[])
>{
>  int i, stat;
>  pthread_mutex_t mutex;
>  pthread_cond_t cond;
>
>  pthread_win32_process_attach_np();
>  pthread_win32_thread_attach_np();
>  stat = pthread_mutex_init(&mutex, NULL);
>  printf("pthread_mutex_init returns %d, errno %d\n", stat, errno);
>
>  stat = pthread_cond_init(&cond, NULL);
>  printf("pthread_cond_init returns %d, errno %d\n", stat, errno);
>
>  stat = pthread_cond_destroy(&cond);
>  printf("pthread_cond_destroy returns %d, errno %d\n", stat, errno);
>
>  stat = pthread_mutex_destroy(&mutex);
>  printf("pthread_mutex_destroy returns %d, errno %d\n", stat, errno);
>
>  getchar();
>}
>
>The output is thus:
>thread_mutex_init returns 0, errno 0
>pthread_cond_init returns 0, errno 0
>pthread_cond_destroy returns 16, errno 0
>pthread_mutex_destroy returns 16, errno 0
>
>Apparently "EBUSY" is returned when there are waiters on synchronization
>objects.  Clearly that can't be the case here so there must be something
>wrong with my port.  The question is - what??  Any ideas on where to
>look or what to do would be vastly appreciated.
>
>TIA,
>craig vanderborgh
>voxware incorporated
>
>
>  
>


This message may contain privileged and/or confidential information.  If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.  Thank you.