Re: problem with CMtex and CSingle lock - WAIT_ABANDONED
Check if your structured exception handlers ever call exit() or
ExitThread(). See if you ever call TerminateThread. See if your architecture
allows threads to die silently.
Check that you don't close the mutex handle while one thread is holding it.
I suspect it also causes WAIT_ABANDONED. A mutex object is not actually
destroyed in the kernel while any thread is holding it, even if all handles
are closed.
Don't use named mutexes, their names can collide with other programs, unless
you really really want to share the mutex across processes.
Abandoned mutex means you really cannot trust your protected data internal
state. You might as well not use a mutex at all. Your best bet in that case
is just abandon the data and restart the service.
"Dh" <tt.dheeraj@gmail.com> wrote in message
news:1156946674.082688.141900@e3g2000cwe.googlegroups.com...
Hi,
Thanks for the response.
In general, make sure you always lock mutexes in the same order - ensure
you have a "lock hierarchy". The code you posted is fine in this
respect, but you may use the locks elsewhere.
Yes. We had a code walkthrough. It did not yeild any potentially
"twisted" locking hierarchy.
In some circumstances(where several threads were spawned) we
encountered a problem in that M2 would held by one thread while M1
would be held by another, resulting in a deadlock.
For investigation purpouses, we derived from CSinglelock, added some
additional logging statements for the ctor, dtor and the Lock and
Unlock methods.
The result was :
When several threads are executing parallely,
we occasionally the CSingle lock in HelperClass::function2 is getting a
value WAIT_ABANDONED. But strangely in our case, the thread which owned
the mutex M2 previously is NOT terminated, but is still alive and is
processing and had released the lock on the mutex M2 properly.
Now the question is, how can the Mutex get abandoned?
When a thread holding the mutex (which, given that the mutex is a named
mutex, could be part of any process) terminates without first releasing
the mutex.
Yes, this is the behaviour noticed in the test programs(run as services
also) that we wrote. But, in the production code, this is not the case.
The destructor of the Single lock is invoked each time and the return
value of CSingleLock::Unlock() is also 1 [double locking does occur in
the code].
Check for WAIT_ABANDONED after you lock each time, and if it happens,
try to lock again. Also, make sure your mutex names are unique to your
service, for obvious reasons - conceivably it could be a usage of your
named mutex from somewhere else that is the problem.
The behaviour noticed is, the thread which got WAIT_ABANDONED while
trying to lock appears to have got the lock since I see other threads
waiting to acquire this. Also, when the deadlock occurs, using process
explorer, the thread that got WAIT_ABANDONED is still holding on to the
lock.
Will try your suggestion to do a double lock in ccase of encountering a
WAIT_ABANDONED.
Warm Regards,
Dheeraj