mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Explaining cond var destroy [Re: [musl] C threads, v3.0]
Date: Wed, 6 Aug 2014 13:32:54 -0400	[thread overview]
Message-ID: <20140806173254.GC1674@brightrain.aerifal.cx> (raw)
In-Reply-To: <1407344216.24324.317.camel@eris.loria.fr>

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


  reply	other threads:[~2014-08-06 17:32 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-04  9:30 C threads, v3.0 Jens Gustedt
2014-08-04  9:33 ` Jens Gustedt
2014-08-04 14:50 ` Rich Felker
2014-08-04 16:48   ` Jens Gustedt
2014-08-04 17:06     ` Rich Felker
2014-08-04 22:16       ` Jens Gustedt
2014-08-04 22:36         ` Rich Felker
2014-08-06  3:52 ` Explaining cond var destroy [Re: [musl] C threads, v3.0] Rich Felker
2014-08-06  8:43   ` Jens Gustedt
2014-08-06  9:41     ` Jens Gustedt
2014-08-06 10:03       ` Rich Felker
2014-08-06 10:32         ` Jens Gustedt
2014-08-06 16:15           ` Rich Felker
2014-08-06 16:56             ` Jens Gustedt
2014-08-06 17:32               ` Rich Felker [this message]
2014-08-06 20:55                 ` Jens Gustedt
2014-08-06 22:04                   ` Rich Felker
2014-08-06 22:43                     ` Jens Gustedt
2014-08-06 23:15                       ` Rich Felker
2014-08-07  7:50                         ` Jens Gustedt
2014-08-07 10:52                           ` Szabolcs Nagy
2014-08-07 11:03                             ` Jens Gustedt
2014-08-07 16:13                           ` Rich Felker
2014-08-07 16:47                             ` Jens Gustedt
2014-08-07 17:25                               ` Rich Felker
2014-08-08  9:20                                 ` Jens Gustedt
2014-08-08 16:53                                   ` Rich Felker
2014-08-08 19:14                                   ` Rich Felker
2014-08-08 20:48                                     ` Rich Felker
2014-08-09  6:47                                       ` Jens Gustedt
2014-08-12  2:50                                         ` Rich Felker
2014-08-12  7:04                                           ` Jens Gustedt
2014-08-12 16:01                                             ` Rich Felker
2014-08-12 19:09                                               ` Jens Gustedt
2014-08-12 21:18                                                 ` Rich Felker
2014-08-13  6:43                                                   ` Jens Gustedt
2014-08-13  7:19                                                     ` Jens Gustedt
2014-08-06  9:50     ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140806173254.GC1674@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).