glibc -- ISO C11 threads Proposal
Rich Felker
dalias@aerifal.cx
Mon Mar 31 14:18:00 GMT 2014
On Mon, Mar 31, 2014 at 09:48:29AM -0400, Kevin Cox wrote:
> On 31/03/14 01:50, Rich Felker wrote:
> >
> > I realized there's an alternate solution to the problem for
> > non-process-shared mutexes: simply keep a count of recursive or
> > error-checking mutexes the current thread owns in its TLS. If, on
> > exit, this count is nonzero, don't actually exit but instead leave the
> > tid permanently tied up until the process exits. (This requires
> > emulating thread exit for pthread_join to work.)
> >
>
> Instead of hanging the thread could the mutex be put in a "permalocked"
> state? For example maybe the stored thread id could be replaced will a
> "null" thread id. This would require reaching into pthread internals
> (assuming we use pthreads to back C11) but this way you can let the
> thread die as the user would expect but the mutex would stay locked forever.
That's the solution which requires space to track all locks held in a
linked list, the "non-alternate" solution.
> > This doesn't work for process-shared mutexes however: once the process
> > exits, the tid could be reused in a completely different process.
>
> This solution doesn't inherently handle the process dying but pthread
> does that for us and will return EOWNERDEAD as long as we are using
> robust mutexes. Then it can simply be pthread_mutex_unlock`ed and it
> will be permanently locked.
>
> This sounds slightly better than hanging the thread but relies on using
> robust pthread objects unless we want to handle dying processes
> ourselves.
It's impossible to handle dying processes. SIGKILL is not catchable.
> I agree that this behaviour is very costly and not very
> useful. I can't imaging any use case where you want a thread holding a
> mutex to die and it is held forever. I'm sure there is one but it seams
> like having a permanently locked mutex lying in your memory is a huge pain.
Indeed, there's no legal way to ever destroy such a mutex..
Rich
More information about the Libc-alpha
mailing list