From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5759 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 13:32:54 -0400 Message-ID: <20140806173254.GC1674@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> 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 1407346396 10278 80.91.229.3 (6 Aug 2014 17:33:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Aug 2014 17:33:16 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5764-gllmg-musl=m.gmane.org@lists.openwall.com Wed Aug 06 19:33:11 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 1XF55I-0000GV-3u for gllmg-musl@plane.gmane.org; Wed, 06 Aug 2014 19:33:08 +0200 Original-Received: (qmail 15729 invoked by uid 550); 6 Aug 2014 17:33: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 15721 invoked from network); 6 Aug 2014 17:33:07 -0000 Content-Disposition: inline In-Reply-To: <1407344216.24324.317.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:5759 Archived-At: On Wed, Aug 06, 2014 at 06:56:56PM +0200, Jens Gustedt wrote: > Am Mittwoch, den 06.08.2014, 12:15 -0400 schrieb Rich Felker: > > One problem with this is that being woken by a signal isn't the only > > way a cond var wait can end. It can also end due to timeout or > > cancellation, and in that case, there's no signaling thread to be > > responsible for the bookkeeping, but if another thread calls > > pthread_cond_broadcast at this point, it can legally destroy and free > > the cond var, despite the timed-out/cancelled wait still having its > > own bookkeeping to do. > > > > The best possible solution would be if we could eliminate the need for > > this bookkeeping entirely, but I don't see any easy way to do that. > > 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 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. I think trying to preclude the possibility of such spurious wakes would require a lot more unlock/destroy synchronization than what we have now in cond vars. Rich