Re: Explaining cond var destroy [Re: [musl] C threads, v3.0]

[Rich Felker <dalias@libc.org>]

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