From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5867 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: New private cond var design Date: Fri, 15 Aug 2014 16:28:13 -0400 Message-ID: <20140815202813.GX12888@brightrain.aerifal.cx> References: <20140815193536.GA26312@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 1408134516 6437 80.91.229.3 (15 Aug 2014 20:28:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Aug 2014 20:28:36 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5873-gllmg-musl=m.gmane.org@lists.openwall.com Fri Aug 15 22:28:30 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XIO6s-0003Us-K6 for gllmg-musl@plane.gmane.org; Fri, 15 Aug 2014 22:28:26 +0200 Original-Received: (qmail 26088 invoked by uid 550); 15 Aug 2014 20:28:25 -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 26080 invoked from network); 15 Aug 2014 20:28:25 -0000 Content-Disposition: inline In-Reply-To: <20140815193536.GA26312@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5867 Archived-At: On Fri, Aug 15, 2014 at 03:35:36PM -0400, Rich Felker wrote: > The list also allows us to eliminate the sequence number wrapping > issue (sadly, only for private, non-process-shared cv's, since > process-shared can't use process-local memory like this) in one of two > ways: > > Option 1: If the list elements store the sequence number their waiter > is waiting on, the signal/broadcast operations can choose a new > sequence number distinct from that of all waiters. I don't think this actually works to avoid the sequence number issue, at least not as-described above, since the sequence number still has to remain unique even once there's a new instance. If we keep a linked list that's not instance-specific but covers all instances, though, we could use it to avoid sequence number reuse, but then some (light, I think) extra accounting is needed to mark what part of the list is from previous instances. > Option 2: Each waiter can wait on a separate futex on its own stack, > so that sequence numbers are totally unneeded. This eliminates all > spurious wakes; signal can precisely control exactly which waiter > wakes (e.g. choosing the oldest), thereby waking only one waiter. > Broadcast then becomes much more expensive: the broadcasting thread > has to make one requeue syscall per waiter. But this still might be a > good design. I think this design is more elegant, and probably performs better in the case where only signal is used since spurious wakes are avoided totally, but somewhat worse when broadcasts are being used. Rich