This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: pthread_mutex_unlock potentially cause invalid access
On Mon, Feb 13, 2012 at 8:01 AM, Atsushi Nemoto <anemo@mba.ocn.ne.jp> wrote:
> On Sun, 12 Feb 2012 17:38:33 -0500, "Carlos O'Donell" <carlos@systemhalted.org> wrote:
>>> On point "A", the mutex is actually unlocked, so other threads can
>>> lock the mutex, unlock, destroy and free. ?If the mutex was destroyed
>>> and freed by other thread, reading '__kind' on point "B" is not valid.
>>
>> No valid conforming program has this behaviour.
> ...
>> If {X-X'} need to be prevented from using M then you need to use
>> *another* synchronization primitive, we call it P, to prevent the use
>> M during the destruction of M.
>
> How about following example in pthread_mutex_destroy manual?
> It seems it can be possible without P.
>
> http://pubs.opengroup.org/onlinepubs/007904875/functions/pthread_mutex_destroy.html
> ------------------------------------------------------------------------
> ? ?Destroying Mutexes
>
> ? ?A mutex can be destroyed immediately after it is unlocked. For
> ? ?example, consider the following code:
>
> ? ?struct obj {
> ? ?pthread_mutex_t om;
> ? ? ? ?int refcnt;
> ? ? ? ?...
> ? ?};
>
> ? ?obj_done(struct obj *op)
> ? ?{
> ? ? ? ?pthread_mutex_lock(&op->om);
> ? ? ? ?if (--op->refcnt == 0) {
> ? ? ? ? ? ?pthread_mutex_unlock(&op->om);
> ? ?(A) ? ? pthread_mutex_destroy(&op->om);
> ? ?(B) ? ? free(op);
> ? ? ? ?} else
> ? ?(C) ? ? pthread_mutex_unlock(&op->om);
> ? ?}
>
> ? ?In this case obj is reference counted and obj_done() is called
> ? ?whenever a reference to the object is dropped. Implementations are
> ? ?required to allow an object to be destroyed and freed and potentially
> ? ?unmapped (for example, lines A and B) immediately after the object is
> ? ?unlocked (line C).
> ------------------------------------------------------------------------
>
> In this example, (A) and (B) can be executed in middle of (C) execution.
> Thus, problem can be happen even on a fully conforming program, no?
No. (A) and (B) can not be executed in the middle of (C).
In my previous example I stated that a synchronizing P would be
required to correctly support the destruction of the mutex.
In this example the synchronizing P is a reference counter.
The threads are serialized by the mutex and only the last thread,
using the reference counter, frees the object.
The assumption is that obj_done() is only called once per thread that
is releasing the object.
Note that the example avoids talking about how you increase the
reference count which is a much more complicated operation to do in a
thread-safe way.
Cheers,
Carlos.