From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5803 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Explaining cond var destroy [Re: [musl] C threads, v3.0] Date: Tue, 12 Aug 2014 12:01:04 -0400 Message-ID: <20140812160103.GB1674@brightrain.aerifal.cx> References: <1407397851.24324.354.camel@eris.loria.fr> <20140807161342.GH1674@brightrain.aerifal.cx> <1407430024.24324.387.camel@eris.loria.fr> <20140807172514.GI1674@brightrain.aerifal.cx> <1407489627.24324.419.camel@eris.loria.fr> <20140808191405.GP1674@brightrain.aerifal.cx> <20140808204855.GQ1674@brightrain.aerifal.cx> <1407566854.4988.231.camel@eris.loria.fr> <20140812025013.GY1674@brightrain.aerifal.cx> <1407827079.15134.109.camel@eris.loria.fr> 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 1407859288 15239 80.91.229.3 (12 Aug 2014 16:01:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 12 Aug 2014 16:01:28 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5809-gllmg-musl=m.gmane.org@lists.openwall.com Tue Aug 12 18:01:19 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 1XHEVi-00051E-HL for gllmg-musl@plane.gmane.org; Tue, 12 Aug 2014 18:01:18 +0200 Original-Received: (qmail 29871 invoked by uid 550); 12 Aug 2014 16:01:17 -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 29860 invoked from network); 12 Aug 2014 16:01:17 -0000 Content-Disposition: inline In-Reply-To: <1407827079.15134.109.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5803 Archived-At: On Tue, Aug 12, 2014 at 09:04:39AM +0200, Jens Gustedt wrote: > > > Generally I think that the control structures should be as tight as > > > possible, give provable properties in the mathematical sense. The > > > interaction between user- and kernelland should be minimal, and we > > > shouldn't provoque reactions of the kernel that concern threads (or > > > even process) that are not really targetted. > > > > The former (provable properties) is definitely a goal we should not > > deviate from. But I don't think the current spurious futex wakes > > conflict with that goal. > > > > The latter (not provoking reactions in untargetted threads) is a > > desirable goal, but not if it conflicts with more important goals like > > avoiding unnecessary allocation (actually, I don't think it's possible > > to solve the problem with allocation; I think an additional layer of > > allocation just makes it worse), fail-safety, performance, etc. > > Did you have a chance to look into my recent implementation of C > threads that I attached to my last post? In particular in > cnd_broadcast you see the advantages, I think: > > - cnd doesn't have to do bookkeeping for the threads waiting on the > condition, the kernel bookkeeping is used for that > > - threads that had to go into futex wait only touch the temporary > structure and this only for the reference count > > - a tight spinlock clearly defines the ordering of the cnd_t > operations Yes, I've spent a total of about 30-45 min reading it, so I have a fairly good idea what it's doing, but my understanding surely has gaps. As far as I can tell, the only thing that's saving you from sending futex wakes after free is that you're just using spinlocks. This is an extremely expensive solution: While contention is rare, as soon as you do hit contention, if there are many threads they all pile on and start spinning, and the time to obtain a lock (and cpu time/energy spent waiting) grows extremely high. And of course it becomes infinite if you have any threads of differing priorities and the low-priority thread has the lock... Rich