Re: glibc -- ISO C11 threads Proposal

[Kevin Cox <kevincox at kevincox dot ca>]

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.

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

Cheers,
Kevin

Attachment: signature.asc
Description: OpenPGP digital signature