From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7344 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Resuming work on new semaphore Date: Sun, 5 Apr 2015 15:02:15 -0400 Message-ID: <20150405190214.GF6817@brightrain.aerifal.cx> References: <20150402013006.GA1108@brightrain.aerifal.cx> <20150402152642.GW6817@brightrain.aerifal.cx> <20150402231457.GC6817@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 1428260552 1485 80.91.229.3 (5 Apr 2015 19:02:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 5 Apr 2015 19:02:32 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7357-gllmg-musl=m.gmane.org@lists.openwall.com Sun Apr 05 21:02:32 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 1YepoU-0006As-T3 for gllmg-musl@m.gmane.org; Sun, 05 Apr 2015 21:02:30 +0200 Original-Received: (qmail 3929 invoked by uid 550); 5 Apr 2015 19:02: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 3901 invoked from network); 5 Apr 2015 19:02:28 -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:7344 Archived-At: On Sun, Apr 05, 2015 at 05:17:35PM +0300, Alexander Monakov wrote: > In a similar vein, if the caller explicitely kills other waiters before > invoking sem_post and sem_getvalue, it will also reveal an inconsistency with > the new implementation: returned value of 0 will look as if sem_post has woken > some waiters, even though the caller could know for certain that no tasks were > waiting on the semaphore. I'm not concerned about async killing (which is something of a broken usage case anyway; it certainly doesn't work for other sync objects except robust mutexes) but I am somewhat concerned about other equivalent cases. For example: 1. Thread A enters sem_wait. 2. Thread B observes thread A in sem_wait via failed sem_trywait. 3. Thread B sends a signal to thread A. 4. Thread A blocks in signal handler waiting for some other event under the control of thread B. 5. Thread B calls sem_post. 6. Thread B calls sem_wait and succeeds. 7. Thread B unblocks thread A. 8. Thread A remains blocked on the sem since B consumed the wake. Note that the same thing happens with the old or new implementation; the only difference is the _values_ observed. I believe this behavior is forbidden by the following: If the semaphore value resulting from this operation is positive, then no threads were blocked waiting for the semaphore to become unlocked; the semaphore value is simply incremented. If the value of the semaphore resulting from this operation is zero, then one of the threads blocked waiting for the semaphore shall be allowed to return successfully from its call to sem_wait()." The old (current) implementation wrongly yields a positive value despite there being waiters. The new implementation wrongly allows sem_wait to succeed (and steal a wake) when the value is zero. > Well we can make sem_getvalue return val[0]+val[1] instead... ;) That just makes the new implementation look like the old one, no? :-) Rich