How to find Unlocked Mutexes in process.

[Raxit]

Hi,

[Sorry for comp.lang.c some folks may find it OT]

In Mulithreaded program, using Posix api, we do
pthread_mutex_l ock(&Lock)
do some ops
if/else/if/else...complex stuff
pthread_mutex_u nlock.
now assume because of complex if/else/if/else, thread got exited
without unlocking the mutex. :)
now the funny part is, other thread trying to acquire lock will
block. How to detect which thread [may be exited thread !!!!] has done
some wrong stuff. But how to track them?

Before few days i posted, why not to unlock all mutex acquired by
thread "A" when thread "A" is exiting/finishing/cancelled/thrown outof
system. !
Please note: from my code i can do manually logs and debug message
monitoring and can findout. What i am more interested in is, "How to
Autodetect and how to avoid, even code is done by ***Lazy***
programmer."

Any thought ?

Cheers,
Raxit

[vippstar]

On May 21, 4:11 pm, "Ra...@MyKavita .com" <raxitsheth2... @gmail.com>
wrote:

Hi,

[Sorry for comp.lang.c some folks may find it OT]

Then why did you post it to comp.lang.c? It doesn't matter who will
find it OT or not, what matters is that your question is not topical
for comp.lang.c. Use common sense.

[=?ISO-8859-1?Q?Marcel_M=FCller?=]

Hi!

Ra***@MyKavita. com schrieb:

now assume because of complex if/else/if/else, thread got exited
without unlocking the mutex. :)
now the funny part is, other thread trying to acquire lock will
block. How to detect which thread [may be exited thread !!!!] has done
some wrong stuff. But how to track them?

Encapsulate the lock and unlock calls in debug builds by a funtion that
does some logging to a file. Always log a timestamp, the called function
(lock/unlock), the address of the Lock and the thread ID. Once you have
a deadlock simply analyze the log and search for the last occourencies
of the handle address of the last call to lock that never returned. You
will find the thread ID of the thread that never unlocked the mutex this
way.
If you frequently start threads, you should also track the thread starts
with some meaningful text to associate a meaningful context with the
thread ID.
Most Unix kernels provide atomic append functions for small amount of
output. So you do not need another mutex to serialize the output.

Before few days i posted, why not to unlock all mutex acquired by
thread "A" when thread "A" is exiting/finishing/cancelled/thrown outof
system. !

You should not compensate for program bugs this way. It is not that
unlikely that other cleanup is also wrong in this case.

Please note: from my code i can do manually logs and debug message
monitoring and can findout. What i am more interested in is, "How to
Autodetect and how to avoid, even code is done by ***Lazy***
programmer."

There is no general way to autodetect deadlocks or unpaired mutex calls.
Only in some rare cases you may catch them safely.

But if C++ is a choice you may use a helper class whose constructor
aquires the lock and whose destructor releases the lock. This is solid
as rock! It is nearly impossible to prevent the destructor call even in
case of exceptions.
Marcel

[Paul Hsieh]

On May 21, 6:11 am, "Ra...@MyKavita .com" <raxitsheth2... @gmail.com>
wrote:

[Sorry for comp.lang.c some folks may find it OT]

Apparently everything related to C is off topic in this newsgroup.
Only the very act of being nit-picky about the current ISO standard is
sanctioned here.

In Mulithreaded program, using Posix api, we do

pthread_mutex_l ock(&Lock)
do some ops
if/else/if/else...complex stuff
pthread_mutex_u nlock.

now assume because of complex if/else/if/else, thread got exited
without unlocking the mutex. :)
now the funny part is, other thread trying to acquire lock will
block. How to detect which thread [may be exited thread !!!!] has done
some wrong stuff. But how to track them?

This is a debugging problem. A Mutex is a lock that is assigned to a
particular thread. A good multi-threaded system should have a way, in
your debugger to know who owns the lock; in fact you might be able to
inspect that from your API (by having a time-out on your MUTEX) and
throw it into some log file somewhere -- i.e., directly instrument
your code to do this sort of analysis. Whenever I have implemented my
own Mutexes from scratch, what I did was I would shove the __FILE__,
__LINE__ macros into the mutex structure to identify the owner because
the point in the code where the Mutex got owned without cleared was
usually more relevant than the thread ID.

Before few days i posted, why not to unlock all mutex acquired by
thread "A" when thread "A" is exiting/finishing/cancelled/thrown outof
system. !

As I said -- this is a debugging problem. You have an error in your
code. You need to isolate the error, not try to vacate the problem
with some trick.

Please note: from my code i can do manually logs and debug message
monitoring and can findout. What i am more interested in is, "How to
Autodetect and how to avoid, even code is done by ***Lazy***
programmer."

This is like the halting problem -- there isn't really a full-proof
way. You can, of course, make a macro with both acquires the lock and
releases it:

#define WITH_MUTEX(mute x,code) { \
int h = mutexAcquire (mutex); \
if (SUCCESS == h) { \
do { code } while (0); \
mutexRelease (mutex); \
} \
}

And in fact you could put in a try+catch thing for C++ to make sure
that you don't escape that way. So you can then set a coding
standard, and in fact have some tool grep through the code and
complain about bare calls to the mutex primitives instead of using the
macro above. But of course, you cannot avoid longjmp() or coroutine
yields anyways, so even with this limited usage there are no
guarantees.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Walter Roberson]

In article <d5************ *************** *******@h1g2000 prh.googlegroup s.com>,
Paul Hsieh <we******@gmail .comwrote:

>On May 21, 6:11 am, "Ra...@MyKavita .com" <raxitsheth2... @gmail.com>
wrote:

>[Sorry for comp.lang.c some folks may find it OT]

>Apparently everything related to C is off topic in this newsgroup.
Only the very act of being nit-picky about the current ISO standard is
sanctioned here.

So, Paul, what do you think about the tradeoffs of using 10W20
as compared to 10W30? And does it make a difference whether it is
synthetic or natural? My wife has cut down on her car use, but
it isn't uncommon for her to pick me up in her 95 Accord after work,
especially if we have to go grocery shopping. The temperature range
here is from about -45C to +35C, with -15C or so being pretty common
in winter outside of the cold snaps; the summer tends to about +25C.

This is, of course, a real-world C situation (since I am a C
programmer), so I figure comp.lang.c oughta be cool with it.
--
"And that's the way it is." -- Walter Cronkite

[Martin Ambuhl]

Paul Hsieh wrote:

On May 21, 6:11 am, "Ra...@MyKavita .com" <raxitsheth2... @gmail.com>
wrote:

>[Sorry for comp.lang.c some folks may find it OT]

Apparently everything related to C is off topic in this newsgroup.
Only the very act of being nit-picky about the current ISO standard is
sanctioned here.

Some people think that posting bullshit claiming that
things-related-to-C are unwelcome in the newsgroup [apparently
comp.lang.c, only one of the three Paul Hsieh crossposted to] is just
what the doctor ordered. It's certainly a lie about comp.lang.c, and
has zero relevance to comp.unix.progr ammer or comp.programmin g.threads.

It is worth noting, that almost nothing can possibly be topical in all
three of the newsgroups to which this thread is crossposted.

I seem to have removed my anti-gmail filter to soon. I'll just
reintroduce one for Paul "Nitwit" Hsieh.

[CBFalconer]

Martin Ambuhl wrote:

Paul Hsieh wrote:

.... snip ...

>

>Apparently everything related to C is off topic in this newsgroup.
Only the very act of being nit-picky about the current ISO
standard is sanctioned here.

Some people think that posting bullshit claiming that
things-related-to-C are unwelcome in the newsgroup [apparently
comp.lang.c, only one of the three Paul Hsieh crossposted to] is
just what the doctor ordered. It's certainly a lie about
comp.lang.c, and has zero relevance to comp.unix.progr ammer or
comp.programmin g.threads.

It is worth noting, that almost nothing can possibly be topical in
all three of the newsgroups to which this thread is crossposted.

I seem to have removed my anti-gmail filter to soon. I'll just
reintroduce one for Paul "Nitwit" Hsieh.

The problem with Hsieh is that he is often violently off-topic here
(in c.l.c), but occasionally makes useful and interesting topical
quotes.

I have set follow-ups to c.l.c, where this is entirely off-topic.
The other groups may well be topical.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.
** Posted from http://www.teranews.com **

[Keith Thompson]

CBFalconer <cb********@yah oo.comwrites:
[...]

I have set follow-ups to c.l.c, where this is entirely off-topic.
The other groups may well be topical.

Are you sure that's what you meant to do, or did you want to redirect
followups to the *other* groups? (This is cross-posted to all three
groups; please limit followups as appropriate.)

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[CBFalconer]

Keith Thompson wrote:

CBFalconer <cb********@yah oo.comwrites:
[...]

>I have set follow-ups to c.l.c, where this is entirely off-topic.
The other groups may well be topical.

Are you sure that's what you meant to do, or did you want to
redirect followups to the *other* groups? (This is cross-posted
to all three groups; please limit followups as appropriate.)

Yup. Because, having snipped it, it only deals with topicality on
c.l.c. Confusing, isn't it? I think this is the right thing to
do.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.
** Posted from http://www.teranews.com **