From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6761 invoked by alias); 13 Dec 2006 09:26:54 -0000 Received: (qmail 6752 invoked by uid 22791); 13 Dec 2006 09:26:53 -0000 X-Spam-Check-By: sourceware.org Received: from py-out-1112.google.com (HELO py-out-1112.google.com) (64.233.166.182) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 13 Dec 2006 09:26:48 +0000 Received: by py-out-1112.google.com with SMTP id p76so85900pyb for ; Wed, 13 Dec 2006 01:26:46 -0800 (PST) Received: by 10.35.100.6 with SMTP id c6mr1212721pym.1166002006811; Wed, 13 Dec 2006 01:26:46 -0800 (PST) Received: by 10.35.126.11 with HTTP; Wed, 13 Dec 2006 01:26:46 -0800 (PST) Message-ID: <321e820c0612130126o3f9d9b98p253d10bd9ebd6370@mail.gmail.com> Date: Wed, 13 Dec 2006 09:26:00 -0000 From: "Sergey Fokin" To: pthreads-win32@sourceware.org Subject: Re: Pthread-win32 races? In-Reply-To: <457FBC2B.8090301@homemail.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <321e820c0612120427t6cff8a59h35eb5fde17a7506f@mail.gmail.com> <457FBC2B.8090301@homemail.com.au> 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/msg00074.txt.bz2 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? > 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? > 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. In this example I can destroy semaphore after pthread_join(). But in my program logic is more complicated and sem_post()'ing thread doesn't finish after sem_post(). And again the same question: Does sem_post() perform atomic access to the semaphore or I should perform additional synchronisation to access the semaphore? Synchronizing access to semaphore looks strange, don't you think so? This quotation is from linux sem_post manual: !sem_post! atomically increases the count of the semaphore pointed to by |sem|. This function never blocks and can safely be used in asyn- chronous signal handlers. So, I think supplied code must be correct according to manual. > 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. Yes, I understand this. And there's no chance to accidentally access destroyed semaphore. -- eof