[Bug nptl/13690] pthread_mutex_unlock potentially cause invalid access

["lopresti at gmail dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=13690

--- Comment #32 from Pat <lopresti at gmail dot com> ---
(In reply to Torvald Riegel from comment #31)
> 
> You can't claim that just one of the semantics is "correct".

Um, actually, you can... Based on (a) the only sane interpretation and (b) THE
ACTUAL EXAMPLE USAGE GIVEN IN THE POSIX SPEC.

> Also, because you mentioned conforming applications: those won't be helped
> by glibc implementing something (incl. something stronger) that's not
> guaranteed by POSIX.

"Hey, POSIX authors, did you actually mean the example code you gave in the,
you know, spec?"

"Yes, we actually meant it."

Is that what you are waiting to hear before you fix this bug? Seriously?

Most people writing "conforming applications" are going to expect the examples
in the spec to... let's see... I dunno... work?

> No, it does not need to be a global lock.  You just make sure that all
> threads that use the resource you want to destruct have quiesced.

To "make sure that all threads ... have quiesced", you must do one of two
things: (a) Rely on some synchronization mechanism, all of which are currently
broken due to this bug; or (b) wait for all threads to exit.

You are arguing for (b): To destroy a mutex -- any mutex -- you must first wait
for every thread that ever touched that mutex to exit.

Is it possible to code against these semantics? Of course. It is also possible
to code without using threads. Or function calls. Or multiplication.

But the whole point of a primitive is to provide useful semantics across a
variety of applications. And by "a variety", I mean more than one (1).

There is one nice thing about this bug, though. It provides a quintessential
(and hilarious) example of why people laugh and roll their eyes when they hear
the phrase "glibc maintainer".

I wonder, what's the over/under on whether this bug gets fixed before 2017?

-- 
You are receiving this mail because:
You are on the CC list for the bug.