From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5764 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: Wed, 6 Aug 2014 19:15:39 -0400 Message-ID: <20140806231539.GE1674@brightrain.aerifal.cx> References: <1407314595.24324.277.camel@eris.loria.fr> <1407318064.24324.282.camel@eris.loria.fr> <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> 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 1407366963 32429 80.91.229.3 (6 Aug 2014 23:16:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Aug 2014 23:16:03 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5769-gllmg-musl=m.gmane.org@lists.openwall.com Thu Aug 07 01:15:56 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 1XFAR0-0000gt-UK for gllmg-musl@plane.gmane.org; Thu, 07 Aug 2014 01:15:55 +0200 Original-Received: (qmail 11663 invoked by uid 550); 6 Aug 2014 23:15:53 -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 11655 invoked from network); 6 Aug 2014 23:15:53 -0000 Content-Disposition: inline In-Reply-To: <1407365015.24324.334.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:5764 Archived-At: On Thu, Aug 07, 2014 at 12:43:35AM +0200, Jens Gustedt wrote: > Am Mittwoch, den 06.08.2014, 18:04 -0400 schrieb Rich Felker: > > No. The problem is that the memory in which the cond var resides could > > previously have been used for a mutex, semaphore, or other object for > > which a futex wait arrives "very late" due to scheduling. It has > > nothing to do with the destruction of cond vars. > > Hm, but then we have a problem on the side that has this late wait, > that is an access to a dead object. So the UB is there, in that thread > that is doing the wait. (Suppose it is just threads and not processes, > that would even be more complicated.) That spurious wakeup that you > are talking about is a consequence of UB. 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. Rich