This is the mail archive of the
pthreads-win32@sources.redhat.com
mailing list for the pthreas-win32 project.
RE: Trouble with mutex/cond destroy on WINCE 3.0
- From: "Craig A. Vanderborgh" <craigv at voxware dot com>
- To: "Bossom, John" <John dot Bossom at Cognos dot COM>
- Cc: 'Ross Johnson' <rpj at ise dot canberra dot edu dot au>, pthreads-win32 at sources dot redhat dot com
- Date: 26 Feb 2003 08:51:52 -0700
- Subject: RE: Trouble with mutex/cond destroy on WINCE 3.0
- References: <BF85C64585F2D61190EF0002A5CE6F3401F12EAD@sottexch2.cognos.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 at ise dot canberra dot edu dot au]
> Sent: Tuesday, February 25, 2003 6:16 PM
> To: Craig A. Vanderborgh
> Cc: pthreads-win32 at sources dot redhat dot 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.