[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 #29 from Torvald Riegel <triegel at redhat dot com> ---
(In reply to Pat from comment #27)
> If you have to wait for all calls to mutex_unlock to return before you can
> destroy the mutex, how are you supposed to guarantee that, exactly?
> 
> You can only do so by synchronizing the threads in some other way. So every
> mutex has to be guarded by another mutex which has to be guarded by another
> mutex...
> 
> ...except for the last mutex, which is global or static or whatever and
> never gets destroyed. Problem solved!

There are other ways to do garbage collection / end-of-lifetime-detection than
doing so via mutex-protected reference counts (and I don't mean you should use
garbage collection for memory management...).

If your mutexes are part of other data structures that you have to destroy, you
can destroy the mutexes when destructing the data structure; unless every
access to the data structure is protected by the mutex, you'll likely need
another mechanism anyway to decide when it's safe to destruct.

> Seriously, think about the kind of code you would have to write to deal with
> these semantics.

I have.  This is a trade-off between implementation constraints and guarantees
given to users, as I pointed out in the POSIX clarification request.  If you
have anything to say about that, then please comment on the POSIX issue.

> Is that what you think POSIX wanted to put people through
> (despite the actual example they give)?

That's what the clarification request is for.

> Is that what glibc wants to put
> people through?

As Carlos said, we're approaching issues like this with the care that is
needed.  This involves making sure that the standards and implementations are
in sync.

> You do not need "clarification" from anybody to recognize that these are
> serious bugs. The only interesting question is how many years it's going to
> take.

It would be a bug if it is not adhering to the specification of the function. 
Arguably, the normative text in the standard can be understood to not allow the
use you seem to want to have.  The POSIX reply will clarify this.

If POSIX clarifies that it wants the strong guarantees re destruction, this is
a bug compared to a clarified standard.  Otherwise, this bug is an enhancement
request, which we would then evaluate as well.

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