This is the mail archive of the
mailing list for the glibc project.
Re: Race unlocking-locking mutex
- From: Ángel González <keisial at gmail dot com>
- To: David Ahern <dsahern at gmail dot com>
- Cc: Carlos O'Donell <carlos at systemhalted dot org>, Godmar Back <godmar at gmail dot com>, "libc-help at sourceware dot org" <libc-help at sourceware dot org>
- Date: Tue, 17 Sep 2013 00:30:29 +0200
- Subject: Re: Race unlocking-locking mutex
- Authentication-results: sourceware.org; auth=none
- References: <5231ECBE dot 4030006 at gmail dot com> <CAB4+JY+dBDVhk9UJWXRXrxF5BhoTFXv==_v+ibdEBU5Noj4aEw at mail dot gmail dot com> <5231F2C3 dot 6080305 at gmail dot com> <CAE2sS1gp9Z5b5qoSqgBXbbL-S+_fHaL1PN7z=CfMsqSTA=7LFg at mail dot gmail dot com> <52336631 dot 5030402 at gmail dot com> <5234CB4C dot 3060305 at gmail dot com> <5234FFFD dot 8070701 at gmail dot com> <52367AF6 dot 1070206 at gmail dot com>
On 16/09/13 05:28, David Ahern wrote:
On 9/14/13 6:31 PM, Ángel González wrote:
Hmm, yes, it seems doable.
I think it could even be implemented without __prev_owner.
This may be such an implementation (to replace the nptl/lowlevellock.h
In my case I am not seeing this code path used. This is linux, x86_64
and from what I can see the code path is:
pthread_mutex_lock == __pthread_mutex_lock()
In the latter you hit the 'simple:' goto path, and then LLL_MUTEX_LOCK
which is a macro to lll_lock and that comes from
I can read asm well enough to get the gist of the code but I do not
know asm near good enough to implement your suggestion below.
Sigh, I was convinced __pthread_mutex_lock() ended up calling
__generic_mutex_lock. I may have confused LLL_MUTEX_LOCK() calls with