Re: Reclaiming locks

Sheth Raxit <raxitsheth2000@xxxxxxxxx> writes:

On Oct 30, 2:13 pm, Måns Rullgård <m...@xxxxxxxxx> wrote:
Sheth Raxit <raxitsheth2...@xxxxxxxxx> writes:
On Oct 30, 2:02 pm, Måns Rullgård <m...@xxxxxxxxx> wrote:
Sheth Raxit <raxitsheth2...@xxxxxxxxx> writes:
On Oct 30, 1:04 am, CJ <diespamm...@xxxxxxxxxxxxxxx> wrote:
Hello Friends -

I've run across the following situation. I have two threads,
say T1 and T2 which access shared data - each locks a mutex
before doing so.

Now I have a hard-to-find bug which means that periodically
T1 gets killed unexpectedly. But if it holds the mutex at
that point, T2 blocks for ever!

How can I get T1 to release any locks it's holding when it
gets killed?

you may want to refer pthread_cleanup_push,pop etc. That is Good Way.

Not really. Using those functions, as well as pthread_cancel(), is
never necessary in a good design.
Why ?

Those functions are only useful if you don't know what your threads
are doing at all times. In a good design you know what's going on,
and there is no need to terminate a thread in an unknown state.

I am being taught it is always good and safer to put clean up code in
multithreaded stuff.

I am telling you it's even safer not to need cleanup in the first place.

--
Måns Rullgård
mans@xxxxxxxxx
.

Relevant Pages

  • Re: Reclaiming locks
    ... T2 which access shared data - each locks a mutex before doing so. ... In a good design you know what's going on, ...
    (comp.unix.programmer)
  • Re: Reclaiming locks
    ... T2 which access shared data - each locks a mutex before doing so. ... In a good design you know what's going on, ...
    (comp.unix.programmer)
  • Re: Reclaiming locks
    ... T2 which access shared data - each locks a mutex before doing so. ... never necessary in a good design. ...
    (comp.unix.programmer)
  • Preemption-related bug in propagate_priority(): its OK to hold Giant but not be running
    ... sodealloctries to destroy the mutex on a socket more than once, ... WITNESS to panic. ... The soft clock ithread preempts the serial output in ... spin locks held: ...
    (freebsd-current)
  • Re: [RFC] locking.9
    ... Sleep Mutexes ... Shared-Exclusive locks ... deschedules the thread while you are holding a SPIN mutex. ... .Ss Sleep Mutexes ...
    (freebsd-current)