This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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
> 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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]