[Bug nptl/13690] pthread_mutex_unlock potentially cause invalid access

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

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

--- Comment #35 from Torvald Riegel <triegel at redhat dot com> ---
(In reply to Rich Felker from comment #34)
> > > 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".
> 
> That requires a mutex. So you just moved the mutex issue to a different
> mutex; you didn't solve it.

Consider a thread pool, or something else that manages a set of threads.  The
lifetime of this thing will be larger than the lifetime of the threads
themselves.  You will want to do pthread_join on the threads eventually, if
you're interested in safe destruction.  Once you do that, you can safely
destruct the thread pool at that time, including any mutexes in it.  If you
want to keep the threads around for longer (e.g., so that they can work on more
than one task), you can easily let them signal the thread pool once they've
finished the task.  For that, you can use a mutex in the thread pool for
example.

Thus, there is a straightforward way to do it without reference counting. 
Having a mutex or similar on the thread pool is not something that's bad.  You
will have the thread pool (or a pthread_t at the very least anyway).

If we didn't have pthread_join, or one would have to implement its
functionality with a pthread_mutex_t, then we would have a problem.  But that's
not the case, we do have pthread_join() to eventually break the chain you seem
to be concerned about.

> > > 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.
> 
> No, you stopped being reasonable several posts back in this thread. I'm not
> sure what your emotional attachment to glibc's current brokenness with
> respect to this issue is, but it's completely clouding your judgement and
> making you look like a fool. It's really sad to see this kind of response to
> bugs again when glibc was just recovering from the madness of the former
> maintainer and his attitude towards bug reports...

I have no emotional attachment to anything here.  That includes the stronger
semantics you want to have, your assumptions about my judgement, etc.

You haven't made a convincing argument why the semantics as targeted by the
current glibc implementation would be incorrect (if the issue above is what
worries you, let's keep discussing that one).  I understood that you'd want
something stronger, and I appreciate that you have an opinion on this, but
ultimately I think glibc should implement what POSIX wants, thus the
clarification request.

Also, if you (and Pat) want the glibc community to be a place where technical
issues are solved in a constructive manner, then you should probably remind
yourselves that you and your actions are very much a part of this.

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