From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7518 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Resuming work on new semaphore Date: Fri, 24 Apr 2015 11:59:02 -0400 Message-ID: <20150424155902.GQ17573@brightrain.aerifal.cx> References: <20150405202314.GG6817@brightrain.aerifal.cx> <20150423160624.GF17573@brightrain.aerifal.cx> <20150424024638.GO17573@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 1429891164 31853 80.91.229.3 (24 Apr 2015 15:59:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Apr 2015 15:59:24 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7531-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 24 17:59:24 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 1Ylg0d-0006vt-2t for gllmg-musl@m.gmane.org; Fri, 24 Apr 2015 17:59:19 +0200 Original-Received: (qmail 1748 invoked by uid 550); 24 Apr 2015 15:59:16 -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 1726 invoked from network); 24 Apr 2015 15:59:15 -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:7518 Archived-At: On Fri, Apr 24, 2015 at 06:47:45PM +0300, Alexander Monakov wrote: > One more thought. In the original proposal, val[1] was a "wake count". By > now we have drifted away a bit from that concept, with val[1] being used not > only in post/timedwait, but also in trywait/getvalue, trywait explicitely > performing post-stealing, and getvalue accounting for that. > > So how about we try to stick with the original vision, and say that val[1] is > strictly for waiters leaving futex wait via non-error path? The kernel tells > the poster via the return value of futex_wake whether the wake has caused any > waiter to resume execution. The kernel already knows if any waiter was there > to accept a wake, and lets us know. Can we somehow use that to implement > non-stealing wakeups? This is the famous problem discussed on libc-alpha in regards to documenting the futex syscall. If you could reliably assume that any zero return from futex wait syscall resulted from an intentional futex wake, this kind of protocol would be possible. Unfortunately almost every existing use of futex wake sends the wake after the memory could already be reused for something new. Fixing this is possible with clever use of FUTEX_WAKE_OP, possibly with a performance hit (but conversely, improving some scheduling behavior), but you'd need a contract that everything agrees to use this protocol. Even one piece of code failing to do so would horribly break code depending on the assumption that "zero means intentional wake". So I don't think it's practical. Also there's the issue that the target may not actually be in the syscall when the wake arrives -- it may be suspended just before it, or in a signal handler. I'm not sure whether those issues are solvable or not. Rich