RE: Trouble with mutex/cond destroy on WINCE 3.0

["Craig A. Vanderborgh" <craigv@voxware.com>]

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.