From owner-freebsd-threads@FreeBSD.ORG Wed Nov 3 15:55:07 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A3CE16A4CE; Wed, 3 Nov 2004 15:55:07 +0000 (GMT) Received: from telecom.net.et (sparrow.telecom.net.et [213.55.64.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8111143D2F; Wed, 3 Nov 2004 15:55:03 +0000 (GMT) (envelope-from mtm@identd.net) Received: from [213.55.68.109] (HELO rogue.acs.lan) by telecom.net.et (CommuniGate Pro SMTP 3.4.8) with ESMTP id 61946468; Wed, 03 Nov 2004 18:47:48 +0300 Received: by rogue.acs.lan (Postfix, from userid 1000) id 77E10B82F; Wed, 3 Nov 2004 18:54:42 +0300 (EAT) Date: Wed, 3 Nov 2004 18:54:42 +0300 From: Mike Makonnen To: Daniel Eischen Message-ID: <20041103155441.GA1601@rogue.acs.lan> References: <20041103141914.GA2095@rogue.acs.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD/6.0-CURRENT (i386) cc: threads@freebsd.org cc: John Baldwin Subject: Re: More mono + libpthread breakage.. X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2004 15:55:07 -0000 On Wed, Nov 03, 2004 at 10:24:10AM -0500, Daniel Eischen wrote: > On Wed, 3 Nov 2004, Mike Makonnen wrote: > > No, the problem has already occurred when sem_post() is called. A signal > occurs while blocked in pthread_cond_wait() but there is a race where the > thread doesn't get removed from the CV queue then calls sem_post() which > tries to requeue the thread on another synchronization queue. Normally > when a signal interrupts a pthread_cond_wait(), the thread should get > removed from the CV queue before calling the signal handler but this > isn't happening. Ok, I misread the problem. However, even if my proposed solution doesn't help, the heart of the problem is that while sem_post is signal-safe, none of the pthreads API is safe. So you can call sem_post from within a signal handler, but sem_post cannot expect to safely call a pthreads function from within the signal handler; therefore, it has to find some other means of synchronization. While it is ok for a pthreads implementation to try to be more robust in these kinds of situations it certainly isn't required by the standard. So sem_post is relying on behaviour that is explicitly *not* guaranteed by POSIX (hence it is in-breach of its signal-safe status). I may be wrong, and welcome any corrections to my interpretation of the situation. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc mtm@identd.net | Fingerprint: AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon !