[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140806173254.GC1674@brightrain.aerifal.cx>
Date: Wed, 6 Aug 2014 13:32:54 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Explaining cond var destroy [Re: C threads, v3.0]
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
