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.