Date: Wed, 6 Aug 2014 19:15:39 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: Explaining cond var destroy [Re: C threads, v3.0] On Thu, Aug 07, 2014 at 12:43:35AM +0200, Jens Gustedt wrote: > Am Mittwoch, den 06.08.2014, 18:04 -0400 schrieb Rich Felker: > > 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. > > Hm, but then we have a problem on the side that has this late wait, > that is an access to a dead object. So the UB is there, in that thread > that is doing the wait. (Suppose it is just threads and not processes, > that would even be more complicated.) That spurious wakeup that you > are talking about is a consequence of UB. No, it's not. The wait happens prior to the deallocation, in the same thread that performs the deallocation. The interleaving looks like this: Thread A Thread B -------- -------- waiters++ save waiters count atomic unlock futex wait fails with EAGAIN cas succeeds & gets lock waiters-- [unlock operation] [free operation] futex wake to freed address The free operation in thread A is valid since A knows it is the last user of the mutex and thread B's use/ownership of the mutex formally ends with the atomic unlock. 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.