This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug nptl/13690] pthread_mutex_unlock potentially cause invalid access
- From: "bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Fri, 20 Dec 2013 22:51:53 +0000
- Subject: [Bug nptl/13690] pthread_mutex_unlock potentially cause invalid access
- Auto-submitted: auto-generated
- References: <bug-13690-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=13690
--- Comment #30 from Rich Felker <bugdal at aerifal dot cx> ---
Carlos, there's nothing "conservative" about giving applications broken
semantics on the basis that you're not sure the standard _requires_ the correct
semantics. And there's no reason to wait for a response from the Austin Group
to fix this. Even if, by some fluke, they removed the requirement that ending
the "reference" to a mutex is atomic with unlocking it, you would still want to
have the correct, safe semantics just for the sake of applications using it.
THIS is the conservative behavior.
Torvald, in regards that there are "other ways" to do end-of-lifetime
detection, the only way to do so in a strictly conforming application, if you
don't have the self-synchronized destruction property for at least one of
mutexes, semaphores, or spinlocks, is with a _global_ lock ensuring that no two
threads can be attempting to release a reference to the same type of
reference-counted object at the same time. This is obviously not practical from
a performance standpoint, and it's also hideous from a "global state considered
harmful" standpoint. Obviously with other tools that will be available in
future editions of POSIX (e.g. C11 atomics) and that are available now as
extensions, you can work around the problem by refraining from using mutexes,
but that's not a good solution.
--
You are receiving this mail because:
You are on the CC list for the bug.