From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16097 invoked by alias); 25 Feb 2003 23:15:54 -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 16089 invoked from network); 25 Feb 2003 23:15:52 -0000 Received: from unknown (HELO real.ise.canberra.edu.au) (137.92.140.34) by 172.16.49.205 with SMTP; 25 Feb 2003 23:15:52 -0000 Received: from ise.canberra.edu.au (special.ise.canberra.edu.au [137.92.140.39]) by real.ise.canberra.edu.au (8.11.6/8.11.6) with ESMTP id h1PNFhh24655; Wed, 26 Feb 2003 10:15:46 +1100 Message-ID: <3E5BF94B.9050109@ise.canberra.edu.au> Date: Tue, 25 Feb 2003 23:15:00 -0000 From: Ross Johnson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Craig A. Vanderborgh" CC: pthreads-win32@sources.redhat.com Subject: Re: Trouble with mutex/cond destroy on WINCE 3.0 References: <1046194147.4455.22.camel@zetar> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003/txt/msg00026.txt.bz2 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 >#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 > > > >