From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7307 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Resuming work on new semaphore Date: Wed, 1 Apr 2015 21:30:06 -0400 Message-ID: <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 1427938230 29587 80.91.229.3 (2 Apr 2015 01:30:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 2 Apr 2015 01:30:30 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7320-gllmg-musl=m.gmane.org@lists.openwall.com Thu Apr 02 03:30:30 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 1YdTxj-0006gK-4N for gllmg-musl@m.gmane.org; Thu, 02 Apr 2015 03:30:27 +0200 Original-Received: (qmail 10152 invoked by uid 550); 2 Apr 2015 01:30:23 -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 10118 invoked from network); 2 Apr 2015 01:30:19 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7307 Archived-At: I have Alexander Monakov's new semaphore design on the agenda for this release cycle (1.1.9). If I remember correctly, we were looking at some issues in the last posted version with barriers and how to write the code in a way that's both clean and avoids compiler stupidity. One other thing I've been thinking about is how the current and new semaphore designs differ when a waiter on a process-shared semaphore is asynchronously killed (while waiting or during acceptance of the post). With the current design: If just waiting, the waiters count remains permanently elevated (and will eventually overflow if this happens billions of times), and any posts will make the value positive so that another waiter can take the post. If accepting (at least one atomic operation on the sem already performed) then the waiters count is left valid and either a post is consumed or left for another waiter to take. With the new design: 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. If accepting, the post is consumed. Accepting only involves one atomic operation so there is no other possibility. It seems to me the behavior for async-kill-while-waiting is somewhat worse with the new design, but this isn't really a usage pattern that should have been considered "supported" before, anyway. If there are ideas to make it better, we could explore them, but I don't think it's a show-stopper in any case. Rich