Date: Thu, 7 Aug 2014 12:13:42 -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 09:50:51AM +0200, Jens Gustedt wrote: > Am Mittwoch, den 06.08.2014, 19:15 -0400 schrieb Rich Felker: > > 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. > > No, operating on an object that has been freed is UB. This is No operation is performed on an object which has been freed. The futex wake is performed on the _address_, not the object, requesting that the kernel use the address as a key into a hash table and wake any threads which are blocked waiting on the futex object associated with that address. The address is never dereferenced. This is the whole point of the current design. > independent of this object being a mutex or not. This must never > happen. So the free is making a wrong assumption. You should clarify whether you mean internal UB in the implementation, or UB in the application. My understanding is that you meant in the implementation, but I claim that's wrong. > I think the fundamental flaw with this approach is that it mixes two > different concepts, the waiters count and a reference count. These are > two different things. No, the waiters count is not used as a reference count. Only the state of the atomic int is used as a reference; once it's set to zero the implementation can no longer access the object (since another thread in the application is free to lock, unlock, destroy, and free it). 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.