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_lock(&Lock)
do some ops
if/else/if/else...complex stuff
pthread_mutex_unlock.


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]

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.

 

[David Schwartz]

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.  !

The short answer is that this is just not how pthread's default mutex
implementation works. You could design a mutex system that worked this
way, and it would have some advantages and some disadvantages over the
way pthread's default mutex works. I think the disadvantages outweigh
the advantages.

The biggest problem is this: with the mutexes pthreads has given us,
it's easy to code mutexes as you suggest. With mutexes as you suggest,
there is no way to code the mutexes POSIX gives us.

The biggest disadvantage is performance. A scheme like you suggest
would require that every time a mutex is locked, some kind of
structure be created somewhere that can be located based on which
thread locked the mutex. Every time the mutex was unlocked, that
structure would have to be removed. There are some tricky cases, like
mutexes may not be unlocked in the same order they are locked.

The other disadvantage is the risk that incorrect behavior will cause
incorrect operation rather than failure. With the current API, if a
thread forgets to unlock a mutex and leaves the data that mutex
protects in an inconsistent state, no other thread will ever be
allowed to lock that mutex, which ensures it will not see the data in
the inconsistent change. With your modification, if a thread fails to
return data to consistent state and terminates while holding a mutex,
no other thread will be permitted to operate on the inconsistent data.
(Of course, the threads may pile up waiting for the mutex, so it won't
magically work perfectly. But failing completely is better than
operating incorrectly.)

DS

 

[Marcel Müller]

Hi!

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]

[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_lock(&Lock)
do some ops
if/else/if/else...complex stuff
pthread_mutex_unlock.

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(mutex,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.

 

[Walter Roberson]

[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.

 

[Martin Ambuhl]

[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.programmer or comp.programming.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.

 

[Keith Thompson]

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.)