This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc -- ISO C11 threads Proposal
- From: Rich Felker <dalias at aerifal dot cx>
- To: Kevin Cox <kevincox at kevincox dot ca>
- Cc: Torvald Riegel <triegel at redhat dot com>, Carlos O'Donell <carlos at redhat dot com>, libc-alpha at sourceware dot org
- Date: Mon, 31 Mar 2014 10:18:42 -0400
- Subject: Re: glibc -- ISO C11 threads Proposal
- Authentication-results: sourceware.org; auth=none
- References: <20140327015642 dot GF26358 at brightrain dot aerifal dot cx> <1395937708 dot 19076 dot 2997 dot camel at triegel dot csb> <20140327170447 dot GJ26358 at brightrain dot aerifal dot cx> <53350719 dot 6090401 at redhat dot com> <20140328053615 dot GM26358 at brightrain dot aerifal dot cx> <1396037667 dot 19076 dot 4026 dot camel at triegel dot csb> <20140328202229 dot GQ26358 at brightrain dot aerifal dot cx> <1396039607 dot 19076 dot 4106 dot camel at triegel dot csb> <20140331055003 dot GE26358 at brightrain dot aerifal dot cx> <5339722D dot 6090403 at kevincox dot ca>
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