From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24372 invoked by alias); 13 Dec 2006 08:39:18 -0000 Received: (qmail 24364 invoked by uid 22791); 13 Dec 2006 08:39:17 -0000 X-Spam-Check-By: sourceware.org Received: from mail.canberra.edu.au (HELO mail.canberra.edu.au) (137.92.97.81) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 13 Dec 2006 08:39:10 +0000 Received: from [137.92.9.97] (noopeebs.canberra.edu.au [137.92.9.97]) by mail.canberra.edu.au (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTPA id <0JA700865EP78P@mail.canberra.edu.au> for pthreads-win32@sourceware.org; Wed, 13 Dec 2006 19:39:07 +1100 (EST) Date: Wed, 13 Dec 2006 08:39:00 -0000 From: Ross Johnson Subject: Re: Pthread-win32 races? In-reply-to: <321e820c0612120427t6cff8a59h35eb5fde17a7506f@mail.gmail.com> To: pthreads-win32@sourceware.org Message-id: <457FBC2B.8090301@homemail.com.au> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Thunderbird 1.5.0.8 (X11/20061105) References: <321e820c0612120427t6cff8a59h35eb5fde17a7506f@mail.gmail.com> X-IsSubscribed: yes Mailing-List: contact pthreads-win32-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sourceware.org X-SW-Source: 2006/txt/msg00073.txt.bz2 Hi Sergey, The library is working correctly since sem_destroy() is returning the error EBUSY as required and documented at: http://sourceware.org/pthreads-win32/manual/sem_init.html This is also in accordance with the Single Unix Specification. If it was hanging your program rather than returning the error then that would be a problem. By the way, in your sample code you don't check the return code from the sem_post(), but the semaphore could already be destroyed at that point. It would be better in this and similar cases to call sem_destroy() after the call to pthread_join(), or at least after you can guarantee that the semaphore is no longer required by any child threads. A sem_t "handle" is not required to be unique in time, so it's possible to destroy a semaphore and init a new one having another purpose altogether, which then by chance occupies the same physical memory location, i.e. has the same "handle" (in pthreads-win32 this is just the pointer to the struct in memory), so a sema op somewhere may not fail even though, logically, it is no longer accessing the semaphore it should be, and the application may now be mysteriously badly behaved and difficult to debug. Regards. Ross Sergey Fokin wrote: > Hi all. > > I have some peculiarities with pthread-win32 and suppose there's a bug > in library. > > Here's my example code: > > #include > #include > #include > #include > > void * thr(void * arg) > { > sem_post((sem_t*)arg); > return 0; > } > > int main() > { > sem_t sem; > int error = 0; > error = sem_init(&sem, 0, 0); // OK > assert(!error); > > pthread_t thread; > error = pthread_create(&thread, 0, thr, &sem); // OK > assert(!error); > > sem_wait(&sem); > error = sem_destroy(&sem); > if (error != 0) > { > error = errno; // errno == 16 (EBUSY) > printf("errno = %d\n", error); > } > > pthread_join(thread, 0); > > return error; > } > > > So, here we have error 16 (0x10) in almost all runs, independently on > compile options (at least i couldn't find working combination). > Compiler is msvc 7.1 sp1. > > I've read about some troubles with it in BUGS file, but first, this > one is unrelated to those, as I can see, second all tests from `tests' > directory run with no errors, but this one fails even with same > compile options. > > When I've tried to debug, it turned out that when main() is executing > sem_destroy(), child thread is still in sem_post(). But I couldn't > find out what's going on there and supposed this is some kind of race, > this is why subject is about races. > > Google didn't find similar issues about pthread-win32 library. > > Really hope, this is my fault, but I have no idea where I'm wrong. > > Thanks in advance. > > PS I'll also try gcc for win32 and msvc8.0 later - I don't have them > on this computer. >