This is the mail archive of the
mailing list for the glibc project.
Re: [RFC][BZ #16159] Detecting that recursive mutex recursed.
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 13 Nov 2013 20:03:56 +0100
- Subject: Re: [RFC][BZ #16159] Detecting that recursive mutex recursed.
- Authentication-results: sourceware.org; auth=none
- References: <20131113134608 dot GA5437 at popelka dot ms dot mff dot cuni dot cz> <20131113181257 dot GT24286 at brightrain dot aerifal dot cx>
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
Do you know how to generate cmpxchgb instruction without lock prefix as
there is no need of interthread synchronization?