From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7311 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Resuming work on new semaphore Date: Thu, 2 Apr 2015 11:26:43 -0400 Message-ID: <20150402152642.GW6817@brightrain.aerifal.cx> 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 1427988419 30185 80.91.229.3 (2 Apr 2015 15:26:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Apr 2015 15:26:59 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7324-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 02 17:26:59 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 1Ydh1G-0002PI-8P for gllmg-musl@m.gmane.org; Thu, 02 Apr 2015 17:26:58 +0200 Original-Received: (qmail 5309 invoked by uid 550); 2 Apr 2015 15:26:56 -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 5285 invoked from network); 2 Apr 2015 15:26:55 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7311 Archived-At: On Thu, Apr 02, 2015 at 10:42:16AM +0300, Alexander Monakov wrote: > 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. Yes, I noticed this too. In that sense, theoretically there should be no harm (aside from eventual overflow of pending wake counter) from having asynchronously-killed waiters, assuming the implementation is bug-free in the absence of async killing of waiters. > 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). Hmm, perhaps that is valid. I'll have to think about it again. I was thinking of having sem_trywait unconditionally down the value (val[0]) then immitate the exit path of sem_timedwait, but that's not valid because another waiter could race and prevent sem_trywait from ever being able to exit. But if it only does the down as a dec-if-positive then it seems like it can safely dec-if-positive the wake count before reporting failure. Rich