[Bug nptl/13690] pthread_mutex_unlock potentially cause invalid access

["triegel at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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

--- Comment #33 from Torvald Riegel <triegel at redhat dot com> ---
(In reply to Pat from comment #32)
> (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.

You're still saying that you like one semantics better than the other.  That
doesn't make another *semantics* incorrect.

> > 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?

If you want to know what I'd like to get clarified by the Austin Group, please
read the Austin group issue.  It should be easy to understand.

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

You can say the same thing about the normative text.  Which brings us right
back to the clarification request...

> > 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;

No, they aren't "broken".  See the examples I gave.

> or (b) wait for all threads to exit.

Precisely, wait for all threads that use the particular resource to not use it
anymore.  That's different from "wait[ing] 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.

This could be a reasonable semantics.

> Is it possible to code against these semantics? Of course.

And often, programs will do just that.  All that don't do reference counting or
similar, for example.

> 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?

This bug is about a technical issue.  I'm not going to respond to off-topic
statements like this.

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