From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4659 invoked by alias); 20 Dec 2006 02:08:44 -0000 Received: (qmail 4584 invoked by uid 22791); 20 Dec 2006 02:08:42 -0000 X-Spam-Check-By: sourceware.org Received: from humvee.dot.net.au (HELO quokka.dot.net.au) (202.147.68.10) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 20 Dec 2006 02:08:33 +0000 Received: from [203.129.40.150] (helo=[203.129.40.150]) by quokka.dot.net.au with esmtp (Exim 3.35 #1 (Debian)) id 1Gwqsf-0000co-00 for ; Wed, 20 Dec 2006 13:08:29 +1100 Message-ID: <45889B1B.6000302@homemail.com.au> Date: Wed, 20 Dec 2006 02:08:00 -0000 From: Ross Johnson User-Agent: Thunderbird 1.5.0.7 (X11/20061008) MIME-Version: 1.0 To: pthreads-win32@sourceware.org Subject: Re: Pthread-win32 races? References: <321e820c0612120427t6cff8a59h35eb5fde17a7506f@mail.gmail.com> In-Reply-To: <321e820c0612120427t6cff8a59h35eb5fde17a7506f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00076.txt.bz2 Sergey Fokin wrote: > Hi all. > > I have some peculiarities with pthread-win32 and suppose there's a bug > in library. Sergey, Although I haven't tested the fix yet, it is possible in the current version for sem_destroy to incorrectly return EBUSY. The problem is in sem_destroy.c. In the sample case, sem_post releases the waiting thread which can then enter sem_destroy while sem_post still holds the mutex guarding the semaphore's state. The EBUSY error results from sem_destroy's "trylock" attempt to acquire that mutex. It should block instead. I'm about to test a fix for this, which if successful will also remove another race that occurs around invalidating the destroyed semaphore. Ross > > 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. >