From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7308 Path: news.gmane.org!not-for-mail From: Alexander Monakov Newsgroups: gmane.linux.lib.musl.general Subject: Re: Resuming work on new semaphore Date: Thu, 2 Apr 2015 10:42:16 +0300 (MSK) Message-ID: References: <20150402013006.GA1108@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: ger.gmane.org 1427960559 22763 80.91.229.3 (2 Apr 2015 07:42:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Apr 2015 07:42:39 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7321-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 02 09:42:31 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YdZlm-0002xZ-83 for gllmg-musl@m.gmane.org; Thu, 02 Apr 2015 09:42:30 +0200 Original-Received: (qmail 9236 invoked by uid 550); 2 Apr 2015 07:42:28 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 8191 invoked from network); 2 Apr 2015 07:42:27 -0000 In-Reply-To: <20150402013006.GA1108@brightrain.aerifal.cx> User-Agent: Alpine 2.11 (LNX 23 2013-08-11) Xref: news.gmane.org gmane.linux.lib.musl.general:7308 Archived-At: On Wed, 1 Apr 2015, Rich Felker wrote: > If just waiting, the negative semaphore value persists after the > waiter is killed. Subsequent posts will produce a wake for a waiter > that doesn't exist, and will thereby allow future waiters that arrive > when the semaphore value is zero to proceed immediately (leaving the > value negative) by consuming this wake. There are usage patterns where > trywait would never succeed again, but wait would succeed trivially. Interesting. To examine the issue under a different light, consider that from the perspective of semaphore implementation, waiters that were killed, stopped, or pre-empted forever in the middle of sem_wait are indistinguishable. Thus, subsequent sem_wait succeeds by effectively stealing a post, and to make things consistent you can teach sem_trywait to steal posts too (i.e. try atomic-decrement-if-positive val[1] just before returning EAGAIN, return 0 if that succeeds). Alexander