This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC][BZ #16159] Detecting that recursive mutex recursed.
- From: Rich Felker <dalias at aerifal dot cx>
- To: Ondrej Bilka <neleai at seznam dot cz>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 13 Nov 2013 13:12:57 -0500
- 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>
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.)
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 works because trylock will succeed if the calling thread already
is the owner of the recursive mutex; if not, pthread_mutex_lock is
safe to call.
Rich