[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140807161342.GH1674@brightrain.aerifal.cx>
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.
