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@xxxxxxxxx> wrote in message
news:1156946674.082688.141900@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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



.

Relevant Pages

  • Re: Recursive mutex that can be waited upon (pthread)
    ... While you can use a mutex to avoid that data is changed, for me having a mutex does not mean that data is not changed, it only means that data is not changed by a different thread. ... My own thread may of course change the data, hence functions I call may want to change the data and if they do so, they must be sure that these changes are atomically, hence they must lock the object and they simply can't rely that I locked the object before -> thus I need recursive locks. ... Then I could as well throw out threads of my code and just use a single thread going through an event queue. ... you have a predicate condition on an invariant. ...
    (comp.programming.threads)
  • [patch 6/8] mutex subsystem, core
    ... mutex implementation, core files: just the basic subsystem, no users of it. ... straightforward mutexes with strict semantics: ... + * Block on a lock - add ourselves to the list of waiters. ...
    (Linux-Kernel)
  • [patch 6/8] mutex subsystem, core
    ... mutex implementation, core files: just the basic subsystem, no users of it. ... straightforward mutexes with strict semantics: ... + * Block on a lock - add ourselves to the list of waiters. ...
    (Linux-Kernel)
  • [PATCH 4/8] adaptive real-time lock support
    ... The Real Time patches to the Linux kernel converts the architecture ... compromising the integrity of critical sections protected by the lock. ... while retaining both the priority inheritance protocol as well as the ... the RT Mutex has been ...
    (Linux-Kernel)
  • Re: WaitForSingleObject() will not deadlock
    ... You keep talking about needing to know the reference count. ... algorithm that uses a recursive mutex that cares in the slightest what the reference count ... attempts to lock appears to be isomorphic to a recursive lock, ... cycle detection until you reach the end of the list, ...
    (microsoft.public.vc.mfc)
Quantcast