This is the mail archive of the glibc-bugs@sourceware.org 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]

[Bug nptl/13690] pthread_mutex_unlock potentially cause invalid access


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.


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