|
Home > Archive > Unix Programming > November 2007 > Reclaiming locks
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| 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?
| |
| Måns Rullgård 2007-10-29, 7:22 pm |
| CJ <diespammers@invalid.invalid> 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
| |
| Keith Thompson 2007-10-29, 7:22 pm |
| CJ <diespammers@invalid.invalid> 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 <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
| |
|
| On 29 Oct 2007 at 21:05, Måns Rullgård wrote:
> CJ <diespammers@invalid.invalid> writes:
>
>
> 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?
| |
| Måns Rullgård 2007-10-29, 7:22 pm |
| CJ <diespammers@invalid.invalid> writes:
> On 29 Oct 2007 at 21:05, Måns Rullgård 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.
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
| |
| David Schwartz 2007-10-30, 1:36 am |
| On Oct 29, 4:24 pm, CJ <diespamm...@invalid.invalid> 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
| |
| Golden California Girls 2007-10-30, 1:36 am |
| CJ wrote:
> On 29 Oct 2007 at 21:05, M�ns Rullg�rd 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?
>
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.
| |
| CBFalconer 2007-10-30, 1:36 am |
| CJ wrote:
> Måns Rullgård 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?
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.
<http://cbfalconer.home.att.net>
--
Posted via a free Usenet account from http://www.teranews.com
| |
| David Schwartz 2007-10-30, 7:32 am |
| On Oct 29, 4:24 pm, CJ <diespamm...@invalid.invalid> 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
| |
| Sheth Raxit 2007-10-30, 7:32 am |
|
On Oct 30, 1:04 am, CJ <diespamm...@invalid.invalid> 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
| |
| Måns Rullgård 2007-10-30, 7:32 am |
| Sheth Raxit <raxitsheth2000@gmail.com> writes:
> On Oct 30, 1:04 am, CJ <diespamm...@invalid.invalid> wrote:
>
> 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
| |
| Sheth Raxit 2007-10-30, 7:32 am |
| On Oct 30, 2:02 pm, M=E5ns Rullg=E5rd <m...@mansr.com> wrote:
> Sheth Raxit <raxitsheth2...@gmail.com> writes:
>
>
>
>
>
> Not really. Using those functions, as well as pthread_cancel(), is
> never necessary in a good design.
Why ?
>
>
> Oh yes.
>
> --
> M=E5ns Rullg=E5rd
> m...@mansr.com
| |
| Måns Rullgård 2007-10-30, 7:32 am |
| Sheth Raxit <raxitsheth2000@gmail.com> writes:
> On Oct 30, 2:02 pm, Måns Rullgård <m...@mansr.com> wrote:
> 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
| |
| Sheth Raxit 2007-10-30, 1:25 pm |
| On Oct 30, 2:13 pm, M=E5ns Rullg=E5rd <m...@mansr.com> wrote:
> Sheth Raxit <raxitsheth2...@gmail.com> writes:
>
and[vbcol=seagreen]
>
ocks[vbcol=seagreen]
>
led?[vbcol=seagreen]
>
y=2E[vbcol=seagreen]
>
>
> 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=E5ns Rullg=E5rd
> m...@mansr.com- Hide quoted text -
>
> - Show quoted text -
| |
| Måns Rullgård 2007-10-30, 7:22 pm |
| Sheth Raxit <raxitsheth2000@gmail.com> writes:
> On Oct 30, 2:13 pm, Måns Rullgård <m...@mansr.com> wrote:
>
> 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
| |
| Boudewijn Dijkstra 2007-11-01, 7:31 am |
| Op Mon, 29 Oct 2007 21:04:12 +0100 schreef CJ
<diespammers@invalid.invalid>:
> 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/
| |
| Boudewijn Dijkstra 2007-11-01, 7:31 am |
| Op Tue, 30 Oct 2007 21:58:27 +0100 schreef Måns Rullgård <mans@mansr.com>:
>
> 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/
|
|
|
|
|