Re: [RFC][BZ #16159] Detecting that recursive mutex recursed.

[OndÅej BÃlka <neleai at seznam dot cz>]

On Wed, Nov 13, 2013 at 01:12:57PM -0500, Rich Felker wrote:
> On Wed, Nov 13, 2013 at 02:46:08PM +0100, Ondrej Bilka wrote:
> > Hi,
> > 
> > To fix bugs with malloc async safety I would need a following primitive
> > 
> > int ptrhead_mutex_lock_cnt(pthread_mutex_t *m, int *cnt);
> > 
> > Which works like pthread_mutex_lock except it returns a number of times lock was recursively locked.
> > This would allow us to detect that function was invoked in signal and provide safe workaround.
> 
> glibc's recursive mutexes are not reentrant, so this will not work.
> You could detect the common case where the interrupted code had
> already fully obtained the mutex, but not the race condition where
> mutex acquisition itself was interrupted. (FYI I have a working
> recursive+reentrant mutex implementation that avoids this issue.)
>
It would require to make mutex reentrant which is separate issue from
proposal.
 
> Anyway, this functionality is not needed for what you want. If
> recursive mutexes were fixed to be reentrant, you could just use the
> following logic:
> 
>     pthread_mutex_trylock(m) || pthread_mutex_lock(m);
> 
This code is equivalent to pthread_mutex_lock(m).

Also this does not solve a problem which was to detect invocation in
signal and use a nonblocking implementation. For that you need to decide
if this condition occured or not.

Alternative solution that I wanted to avoid is to use additional
thread-local variable to detect signals. A count would be maintained by
atomic increment/decrement.

Do you know how to generate cmpxchgb instruction without lock prefix as
there is no need of interthread synchronization?