Re: pthread_mutex_unlock potentially cause invalid access

[Atsushi Nemoto <anemo at mba dot ocn dot ne dot jp>]

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?

---
Atsushi Nemoto