From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9588 invoked by alias); 13 Dec 2006 14:26:08 -0000 Received: (qmail 9578 invoked by uid 22791); 13 Dec 2006 14:26:08 -0000 X-Spam-Check-By: sourceware.org Received: from canyonero.dot.net.au (HELO canyonero.dot.net.au) (202.147.68.14) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 13 Dec 2006 14:25:59 +0000 Received: from [203.129.46.14] (helo=[203.129.46.14]) by canyonero.dot.net.au with esmtp (Exim 3.35 #1 (Debian)) id 1GuV3U-0005lo-00 for ; Thu, 14 Dec 2006 01:25:56 +1100 Message-ID: <45800D72.4070309@homemail.com.au> Date: Wed, 13 Dec 2006 14:26: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> <457FBC2B.8090301@homemail.com.au> <321e820c0612130126o3f9d9b98p253d10bd9ebd6370@mail.gmail.com> In-Reply-To: <321e820c0612130126o3f9d9b98p253d10bd9ebd6370@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/msg00075.txt.bz2 Sergey Fokin wrote: > Hello. > >> 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. > > The sem_destroy function sets errno to the following error code on error: > EBUSY if some threads are currently blocked waiting on the semaphore. > > But there's obviously no threads waiting on semaphore, is there? My apologies - I didn't even see the sem_wait() even though it's right before the sem_destroy(), and regardless, as you say, it should only return EBUSY if someone is waiting, not posting. It's been a while but the code looks like it tries to ensure this. I'll have to look closer when I'm more awake. > >> 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 couldn't (shouldn't, because actually it does). Because semaphore > is destroyed only after sem_wait(), but sem_wait() returns (should > return) only after sem_post() succeeds. Did I understood right? As above - my mistake. Ross