[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 7 Aug 2014 12:52:22 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Explaining cond var destroy [Re: C threads, v3.0]
* Jens Gustedt <jens.gustedt@...ia.fr> [2014-08-07 09:50:51 +0200]:
> 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
> independent of this object being a mutex or not. This must never
> happen. So the free is making a wrong assumption.
>
> 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.
>
> With a reference count, the schema looks like this.
>
> Initially the "obj->refs" counter is at least 2 because both threads
> hold references on the object.
>
> Thread A Thread B
> -------- --------
> waiters++
> save waiters count
> atomic unlock
> futex wait fails with EAGAIN
> cas succeeds & gets lock
> waiters--
> [unlock operation]
> if (atomic_fetch_sub(&obj->refs,1) == 1)
> [free operation on obj]
>
> futex wake to freed address
> if (atomic_fetch_sub(&obj->refs,1) == 1)
> [free operation on obj]
>
> Which thread does the free operation (if any), only depends on the
> order in which the atomic_fetch_sub operations are effective. (And
> musl doesn't seem to have the primitives to do atomic_fetch_sub?)
>
> Now I am aware that such a scheme is difficult to establish in a
> setting where obj can be malloced of not. This scenario supposes that
> both threads *know* that the allocation of obj has been done with
> malloc.
>
i havent followed all the discussions so i dont know if
this is libc internal only or exposed to the user (who
does the free)
but the locking behaviour exposed to the user should
be such that this pattern works:
mutex_lock(obj->lock);
c = --obj->refs;
mutex_unlock(obj->lock);
if (!c)
free(obj);
if it does not work then there will be hard to debug bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=13690
http://austingroupbugs.net/view.php?id=811
http://lwn.net/Articles/575477/
https://lists.gnu.org/archive/html/qemu-devel/2014-02/msg04583.html
> The easiest way to assure that, would be to impose that the "real"
> data object that the thread lock, unlock, wait etc operations would
> use would always have to be malloced.
>
> For C threads this can be done by mtx_init and cnd_init. They would
> be allocating the dynamic object, set "refs" to 1 and set a link to
> that object. For mtx_t and cnd_t dynamic initialization is imperative.
>
dynamic allocation per mutex or cond var sounds bad
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.
