From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31426 invoked by alias); 26 Feb 2003 16:06:34 -0000 Mailing-List: contact pthreads-win32-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sources.redhat.com Received: (qmail 31415 invoked from network); 26 Feb 2003 16:06:33 -0000 Received: from unknown (HELO calypsoo.voxware.com) (63.167.41.125) by 172.16.49.205 with SMTP; 26 Feb 2003 16:06:33 -0000 Received: from zetar (12-253-95-100.client.attbi.com [12.253.95.100]) by calypsoo.voxware.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FTC8Z4KA; Wed, 26 Feb 2003 10:49:01 -0500 Subject: RE: Trouble with mutex/cond destroy on WINCE 3.0 From: "Craig A. Vanderborgh" To: "Bossom, John" Cc: 'Ross Johnson' , pthreads-win32@sources.redhat.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 26 Feb 2003 16:06:00 -0000 Message-Id: <1046274715.4455.34.camel@zetar> Mime-Version: 1.0 X-SW-Source: 2003/txt/msg00028.txt.bz2 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 > >#include > > > >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.