From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5762 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 18:04:53 -0400 Message-ID: <20140806220453.GD1674@brightrain.aerifal.cx> References: <1407144603.8274.248.camel@eris.loria.fr> <20140806035213.GR1674@brightrain.aerifal.cx> <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> 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 1407362721 17880 80.91.229.3 (6 Aug 2014 22:05:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Aug 2014 22:05:21 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5767-gllmg-musl=m.gmane.org@lists.openwall.com Thu Aug 07 00:05:15 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 1XF9KW-0004mZ-Ev for gllmg-musl@plane.gmane.org; Thu, 07 Aug 2014 00:05:08 +0200 Original-Received: (qmail 26609 invoked by uid 550); 6 Aug 2014 22:05:07 -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 26597 invoked from network); 6 Aug 2014 22:05:06 -0000 Content-Disposition: inline In-Reply-To: <1407358510.24324.328.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:5762 Archived-At: On Wed, Aug 06, 2014 at 10:55:10PM +0200, Jens Gustedt wrote: > Am Mittwoch, den 06.08.2014, 13:32 -0400 schrieb Rich Felker: > > On Wed, Aug 06, 2014 at 06:56:56PM +0200, Jens Gustedt wrote: > > > Easy perhaps not. But the futex syscall returns some of the > > > information that is currently thrown away. > > > > Sadly it seems like a bad idea to rely on any of the information > > returned by the futex syscall, due to the possibility of spurious > > wakes coming from reuse of memory. This is discussed somewhat on glibc > > issue 13690: > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=13690 > > that is a complicated thread, I am not sure that I captured all > aspects Yes, I think not.. :) The issue I'm talking about now doesn't come up until near the end of the thread and it's in regards to whether it's safe to call futex wake on an address that's no longer owned at the time of the wake. > > The core issue is that, when performing operations like a mutex > > unlock, we can only know if futex wake is needed _after_ the atomic > > release action has been performed, and at that point, the address on > > which the futex wake is performed may no longer be valid, or may have > > been reallocated for another use. Thus, futex wait for a new > > synchronization object can spuriously return 0. > > *If* we suppose that your destroy-wait trick works (and I think it > does) such a reuse for pthread_cond_t can never happen, and thus the > futex-syscall should return the correct values. I'll try to work some > simplification from there. 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. Rich