Pthreads: how to insure mutex is unlocked when a thread dies.

(I looked in the SUN pthreads book, the Solaris 10 man pages, and in
the c.p.t FAQ,
and didn't find anything about this.)

I'm writing an application that will spin off a thread to handle
incoming messages
from another system. In the past, we've had problems with such threads
dying,
e.g., due to a SEGV or something, and the rest of the program merrily
going
on, not noticing that the thread is gone.

Anyway, I was planning to have this thread lock a mutex when it starts,
and
unlock it when it's done, e.g., when the application notifies it to
quit. The
application will set the notification variable, and then wait on the
mutex.

I'm concerned that if the thread dies before the application notifies
it to quit, the
lock will never get unlocked.

I'm using C++, and have an RAII class that will release the lock in
case of
an exception or other return, but I haven't been able to find out
whether this
will also handle things like SEGV.

1. Will this handle abnormal termination, such as SEGV in the thread?

2. If not, is there a good way to make sure the mutex is unlocked,
regardless
of how the thread dies?

Our applications are sort of like server applications -- they run
without much
active supervision, and they have to raise a alarm (or crash) in order
to get
Operations to look at them -- so they have to behave in some sensible
fashion
even when they have errors.


-- Alan McKenney

.

Relevant Pages

  • Re: A scoped lock/unlock implementation in C++.
    ... mutex_locker wrapping the same mutex, more than one thread won't share ... But beyond that it will still work with thread local mutex_locker instances, since no two threads can have a nonzero lock count anyway. ... When entering a locked region, if the last entry is negative, you know ... In case of unlocks even the unlock count is insignificant. ...
    (comp.programming.threads)
  • Re: How to check if a mutex is still locked?
    ... Shared resource should only be handled inside critical regions ... particular mutex mentioned in the initial message. ... lock the_super_mutex ... unlock the_super_mutex ...
    (comp.programming.threads)
  • Re: A scoped lock/unlock implementation in C++.
    ... namely a guarantee that a scoped_unlock *will* unlock the mutex lock ... You may protect the mutex::lock and unlock functions and declare the ... lock function and a locked flag. ...
    (comp.programming.threads)
  • Re: double-checked locking in C
    ... Except that threads may never lock the mutex. ... guarantee they'll ever see the initialization. ... you don't call 'lock' or 'unlock' if the initialization ...
    (comp.programming.threads)
  • Re: Recursive mutex that can be waited upon (pthread)
    ... While you can use a mutex to avoid that data is changed, for me having a mutex does not mean that data is not changed, it only means that data is not changed by a different thread. ... My own thread may of course change the data, hence functions I call may want to change the data and if they do so, they must be sure that these changes are atomically, hence they must lock the object and they simply can't rely that I locked the object before -> thus I need recursive locks. ... Then I could as well throw out threads of my code and just use a single thread going through an event queue. ... you have a predicate condition on an invariant. ...
    (comp.programming.threads)