Date: Sun, 5 Apr 2015 15:02:15 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: Resuming work on new semaphore 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+val instead... ;) That just makes the new implementation look like the old one, no? :-) Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.