[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 #31 from Torvald Riegel <triegel at redhat dot com> ---
(In reply to Rich Felker from comment #30)
> 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.

You can't claim that just one of the semantics is "correct".  They, obviously,
can both be used in meaningful ways.  We can certainly argue about the utility
of both of the semantics, but that's different from correctness.

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

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

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.  For example, if
you've spawned a set of threads to do work concurrently on a resource, and join
them after they've done the job, then pthread_join does exactly this for you;
afterwards, whichever thread spawned those threads can initiate destruction. 
If you've used a task queue or similar on a thread pool, the task queue can do
the same.

> This is obviously not practical
> from a performance standpoint,

I don't see how the thread pool, for example, is bad in terms of performance.

> and it's also hideous from a "global state
> considered harmful" standpoint.

This is not about global vs. non-global state, but instead about how to ensure
quiescence of concurrent threads: you initiate concurrent execution, and once
that's done and there's no concurrency anymore, you destruct.  The main thread
might be the thread that's doing that, and it might use global state for that,
but that's not necessarily so.

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