From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7345 Path: news.gmane.org!not-for-mail From: Alexander Monakov Newsgroups: gmane.linux.lib.musl.general Subject: Re: Resuming work on new semaphore Date: Sun, 5 Apr 2015 23:03:34 +0300 (MSK) Message-ID: References: <20150402013006.GA1108@brightrain.aerifal.cx> <20150402152642.GW6817@brightrain.aerifal.cx> <20150402231457.GC6817@brightrain.aerifal.cx> <20150405190214.GF6817@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 1428264229 24034 80.91.229.3 (5 Apr 2015 20:03:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 5 Apr 2015 20:03:49 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7358-gllmg-musl=m.gmane.org@lists.openwall.com Sun Apr 05 22:03:49 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 1Yeqlo-0004fS-4j for gllmg-musl@m.gmane.org; Sun, 05 Apr 2015 22:03:48 +0200 Original-Received: (qmail 17846 invoked by uid 550); 5 Apr 2015 20:03:46 -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 17825 invoked from network); 5 Apr 2015 20:03:45 -0000 In-Reply-To: <20150405190214.GF6817@brightrain.aerifal.cx> User-Agent: Alpine 2.11 (LNX 23 2013-08-11) Xref: news.gmane.org gmane.linux.lib.musl.general:7345 Archived-At: On Sun, 5 Apr 2015, Rich Felker wrote: > 1. Thread A enters sem_wait. > 2. Thread B observes thread A in sem_wait via failed sem_trywait. Hm, I don't see how that can be achieved. As a result I'm afraid I didn't fully understand your example. > > Well we can make sem_getvalue return val[0]+val[1] instead... ;) > > That just makes the new implementation look like the old one, no? :-) Can't be bad if it behaves the same but works a bit faster. Apropos, like I've said on IRC, looks like there's "semaphore uncertainty principle": that formal semaphore value is between val[0] and (val[0] +/- val[1]) (clamped to 0 as needed). It seems you can either do your hack and pretend that there are never any waiters, or try to faithfully count waiters in sem_getvalue, but then also reveal that sometimes the implementation works by stealing a post. I believe you could argue that the latter is explicitely disallowed by the spec. By the way, I think there's an interesting interplay with cancellation. Consider the following. Thread B does "return sem_wait(sem);". Thread A does: pthread_cancel(thread_B); sem_post(sem); sem_getvalue(sem); If it observes semaphore value as 1 it follows that thread B has not become a waiter yet, and since it must have cancellation already pending, it may not consume the post. And yet if thread B is already futex-waiting in sem_wait, consuming the post takes priority over acting on cancellation. So if then thread A does pthread_join(thread_B); sem_getvalue(sem); and gets value of 0, it sees a contradiction. And return value from pthread_join will indicate that thread_B exited normally rather than was cancelled. And on the contrary, if you make acting on cancellation/timeout take priority, you can observe semaphore value increasing when waiters leave the wait on error path without consuming the post. Alexander