From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5772 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: Thu, 7 Aug 2014 12:13:42 -0400 Message-ID: <20140807161342.GH1674@brightrain.aerifal.cx> References: <20140806100335.GV1674@brightrain.aerifal.cx> <1407321172.24324.287.camel@eris.loria.fr> <20140806161552.GB1674@brightrain.aerifal.cx> <1407344216.24324.317.camel@eris.loria.fr> <20140806173254.GC1674@brightrain.aerifal.cx> <1407358510.24324.328.camel@eris.loria.fr> <20140806220453.GD1674@brightrain.aerifal.cx> <1407365015.24324.334.camel@eris.loria.fr> <20140806231539.GE1674@brightrain.aerifal.cx> <1407397851.24324.354.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 1407428046 17811 80.91.229.3 (7 Aug 2014 16:14:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Aug 2014 16:14:06 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5777-gllmg-musl=m.gmane.org@lists.openwall.com Thu Aug 07 18:14:00 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 1XFQKB-0008BW-RP for gllmg-musl@plane.gmane.org; Thu, 07 Aug 2014 18:13:55 +0200 Original-Received: (qmail 23560 invoked by uid 550); 7 Aug 2014 16:13:55 -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 23552 invoked from network); 7 Aug 2014 16:13:54 -0000 Content-Disposition: inline In-Reply-To: <1407397851.24324.354.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:5772 Archived-At: On Thu, Aug 07, 2014 at 09:50:51AM +0200, Jens Gustedt wrote: > Am Mittwoch, den 06.08.2014, 19:15 -0400 schrieb Rich Felker: > > No, it's not. The wait happens prior to the deallocation, in the same > > thread that performs the deallocation. The interleaving looks like > > this: > > > > Thread A Thread B > > -------- -------- > > waiters++ > > save waiters count > > atomic unlock > > futex wait fails with EAGAIN > > cas succeeds & gets lock > > waiters-- > > [unlock operation] > > [free operation] > > futex wake to freed address > > > > The free operation in thread A is valid since A knows it is the last > > user of the mutex and thread B's use/ownership of the mutex formally > > ends with the atomic unlock. > > No, operating on an object that has been freed is UB. This is No operation is performed on an object which has been freed. The futex wake is performed on the _address_, not the object, requesting that the kernel use the address as a key into a hash table and wake any threads which are blocked waiting on the futex object associated with that address. The address is never dereferenced. This is the whole point of the current design. > independent of this object being a mutex or not. This must never > happen. So the free is making a wrong assumption. You should clarify whether you mean internal UB in the implementation, or UB in the application. My understanding is that you meant in the implementation, but I claim that's wrong. > I think the fundamental flaw with this approach is that it mixes two > different concepts, the waiters count and a reference count. These are > two different things. No, the waiters count is not used as a reference count. Only the state of the atomic int is used as a reference; once it's set to zero the implementation can no longer access the object (since another thread in the application is free to lock, unlock, destroy, and free it). Rich