Reclaiming locks - Unix

This is a discussion on Reclaiming locks - Unix ; 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 ...

+ Reply to Thread
Results 1 to 17 of 17

Thread: Reclaiming locks

  1. Reclaiming locks

    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?


  2. Re: Reclaiming locks

    CJ writes:

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


    Find and fix the bug that gets it killed. Anything else will only
    cause you more trouble later on.

    Follow-ups set to comp.unix.programmer as this is not directly related
    to the C language.

    --
    Måns Rullgård
    mans@mansr.com

  3. Re: Reclaiming locks

    CJ writes:
    > 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?


    Standard C has no threads, so comp.lang.c isn't the place to ask about this.

    I've redirected followups to just comp.unix.programmer (not that it
    will do any good), but comp.programming.threads might also be a good
    place to ask.

    --
    Keith Thompson (The_Other_Keith) kst-u@mib.org
    San Diego Supercomputer Center <*>
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

  4. Re: Reclaiming locks

    On 29 Oct 2007 at 21:05, Måns Rullgård wrote:
    > CJ writes:
    >
    >> 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?

    >
    > Find and fix the bug that gets it killed. Anything else will only
    > cause you more trouble later on.


    I promise you, not fixing the bug is not the result of lack of will! It
    basically comes down to some completely unmanageable and unpenetrable
    code that we have to work with. We can basically work around the bug,
    but the only problem is the dead thread keeping its locks - there must
    be a solution to that?


  5. Re: Reclaiming locks

    CJ writes:

    > On 29 Oct 2007 at 21:05, Måns Rullgård wrote:
    >> CJ writes:
    >>
    >>> 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?

    >>
    >> Find and fix the bug that gets it killed. Anything else will only
    >> cause you more trouble later on.

    >
    > I promise you, not fixing the bug is not the result of lack of will! It
    > basically comes down to some completely unmanageable and unpenetrable
    > code that we have to work with.


    Then rewrite the code from scratch.

    > We can basically work around the bug, but the only problem is the
    > dead thread keeping its locks - there must be a solution to that?


    No, there is no solution. If the dead thread was holding a lock, it
    may well have left something in an inconsistent state. That is
    usually the reason for using locks in the first place.

    Not including comp.lang.c at all this time since your news reader
    doesn't seem to understand the Followup-To header, and threading
    problems are still off-topic there.

    --
    Måns Rullgård
    mans@mansr.com

  6. Re: Reclaiming locks

    On Oct 29, 4:24 pm, CJ wrote:

    > I promise you, not fixing the bug is not the result of lack of will! It
    > basically comes down to some completely unmanageable and unpenetrable
    > code that we have to work with. We can basically work around the bug,
    > but the only problem is the dead thread keeping its locks - there must
    > be a solution to that?


    Run the broken code in its own process. Threads are not isolated from
    each other. There is no such thing as a "dead thread", only a crashed
    process.

    DS




  7. Re: Reclaiming locks

    CJ wrote:
    > On 29 Oct 2007 at 21:05, M�ns Rullg�rd wrote:
    >> CJ writes:
    >>
    >>> 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?

    >> Find and fix the bug that gets it killed. Anything else will only
    >> cause you more trouble later on.

    >
    > I promise you, not fixing the bug is not the result of lack of will! It
    > basically comes down to some completely unmanageable and unpenetrable
    > code that we have to work with. We can basically work around the bug,
    > but the only problem is the dead thread keeping its locks - there must
    > be a solution to that?
    >


    Install a signal handler to catch the bug and in the handler unlock the mutex
    before you call pthread_exit. What additional bugs you cause by this is your
    problem to debug.




  8. Re: Reclaiming locks

    CJ wrote:
    > Måns Rullgård wrote:
    >> CJ writes:
    >>
    >>> 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?

    >>
    >> Find and fix the bug that gets it killed. Anything else will
    >> only cause you more trouble later on.

    >
    > I promise you, not fixing the bug is not the result of lack of
    > will! It basically comes down to some completely unmanageable
    > and unpenetrable code that we have to work with. We can basically
    > work around the bug, but the only problem is the dead thread
    > keeping its locks - there must be a solution to that?


    I thought you had already been told this is off-topic on c.l.c,
    because standard C has no threads. You need a newsgroup that deals
    with your system, such as comp.unix.programmer.

    --
    Chuck F (cbfalconer at maineline dot net)
    Available for consulting/temporary embedded and systems.




    --
    Posted via a free Usenet account from http://www.teranews.com


  9. Re: Reclaiming locks

    On Oct 29, 4:24 pm, CJ wrote:

    > I promise you, not fixing the bug is not the result of lack of will! It
    > basically comes down to some completely unmanageable and unpenetrable
    > code that we have to work with. We can basically work around the bug,
    > but the only problem is the dead thread keeping its locks - there must
    > be a solution to that?


    Run the broken code in its own process. Threads are not isolated from
    each other. There is no such thing as a "dead thread", only a crashed
    process.

    DS




  10. Re: Reclaiming locks


    On Oct 30, 1:04 am, CJ 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.

    < Now I would doubt, you have mentioned **killed**, but actually it is
    killed ? or cancelled ? or exited ? because of Bug. Did you check
    using Debugger/implemeting signal handler it is killed ?>

    apart from that, you may need to Identify/Fix the Bug !


    Cheers,
    Raxit
    www.barcamp.org/BarCampAhmedabad


  11. Re: Reclaiming locks

    Sheth Raxit writes:

    > On Oct 30, 1:04 am, CJ 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.

    > apart from that, you may need to Identify/Fix the Bug !


    Oh yes.

    --
    Måns Rullgård
    mans@mansr.com

  12. Re: Reclaiming locks

    On Oct 30, 2:02 pm, Måns Rullgård wrote:
    > Sheth Raxit writes:
    > > On Oct 30, 1:04 am, CJ 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 ?
    >
    > > apart from that, you may need to Identify/Fix the Bug !

    >
    > Oh yes.
    >
    > --
    > Måns Rullgård
    > m...@mansr.com




  13. Re: Reclaiming locks

    Sheth Raxit writes:

    > On Oct 30, 2:02 pm, Måns Rullgård wrote:
    >> Sheth Raxit writes:
    >> > On Oct 30, 1:04 am, CJ 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.

    --
    Måns Rullgård
    mans@mansr.com

  14. Re: Reclaiming locks

    On Oct 30, 2:13 pm, Måns Rullgård wrote:
    > Sheth Raxit writes:
    > > On Oct 30, 2:02 pm, Måns Rullgård wrote:
    > >> Sheth Raxit writes:
    > >> > On Oct 30, 1:04 am, CJ wrote:
    > >> >> Hello Friends -

    >
    > >> >> I've run across the following situation. I have two threads, say T1and
    > >> >> 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.

    >
    > --
    > Måns Rullgård
    > m...@mansr.com- Hide quoted text -
    >
    > - Show quoted text -




  15. Re: Reclaiming locks

    Sheth Raxit writes:

    > On Oct 30, 2:13 pm, Måns Rullgård wrote:
    >> Sheth Raxit writes:
    >> > On Oct 30, 2:02 pm, Måns Rullgård wrote:
    >> >> Sheth Raxit writes:
    >> >> > On Oct 30, 1:04 am, CJ 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@mansr.com

  16. Re: Reclaiming locks

    Op Mon, 29 Oct 2007 21:04:12 +0100 schreef CJ
    :
    > 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!


    That problem is inherent to mutexes. If your system has a task
    investigation API and supports atomic operations, you could record the
    owner task and see whether it's still alive. The cleanest option would be
    to use a proper messaging API.

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


    Add a task kill hook?



    --
    Gemaakt met Opera's revolutionaire e-mailprogramma:
    http://www.opera.com/mail/

  17. Re: Reclaiming locks

    Op Tue, 30 Oct 2007 21:58:27 +0100 schreef Måns Rullgård :
    >> 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.


    There are always safer options, up to and beyond not switching on your
    computer.



    --
    Gemaakt met Opera's revolutionaire e-mailprogramma:
    http://www.opera.com/mail/

+ Reply to Thread