Re: CSingleLock - known behaviour?
On Thu, 26 Jun 2008 00:34:51 -0700 (PDT), neilsolent
<neil@solenttechnology.co.uk> wrote:
It is really very simple, I am surprised you can't imagine any example
of this, e.g:
void Function1()
{
CSingleLock mylock(&lock, FALSE);
I would distinguish between the synchronization object "lock" and the lock
object "mylock". I like to use "mx" as a generic mutex name and "lk" as a
generic lock object name:
CSingleLock lk(&mx, FALSE);
if ( ...condition1 ..)
{
lock.Lock();
See how confusing it is? You should be locking "mylock".
// do something with shared resource
}
if ( ... condition2 ..)
{
lock.Lock();
// do something else with shared resource
}
}
sometimes condition1 will be true, sometimes condition2, and sometimes
both.
My first question would be whether it's valid to test the conditions
without holding the lock. (Google "double checked locking pattern" to see
how subtle this can be to determine.) My second thought would be to
consider what it means for condition1 to be true. When condition1 is true,
the testing of condition2 and the (possible) execution of its block is
atomic WRT the execution of the code in the first block, and there is a
memory barrier before the testing of condition2 that is not present when
condition1 is false. This could hide bugs which may reveal themselves when
condition1 happens to be false. Depending on what condition2 does, it can
also make it harder to reason about deadlock scenarios, because the mutex
may or may not be held when condition2 is evaluated.
So as a general rule, I prefer to avoid situations in which a lock may or
may not be held, as is the case for the evaluation of your condition2,
because it increases complexity. I would lean to locking the whole
function, or if it is truly valid to test the conditions without holding
the lock, getting rid of the function-wide lock object and using local
locks inside the controlled blocks.
Nope, I only use CSingleLock on the stack, and only by one thread. I
wouldn't dream of doing any of these things you mention.
I use IsLocked() only in my SafeLock() function as a programming best
practice - to write neater code, where I don't have to keep checking
the state of CSingleLock.
My code is advanced in terms of intricate thread interactions.
Sure, but I'm wondering if it would be possible and reasonable to eliminate
checking the state, in the interest of simplifying and improving the
design, which helps a lot with correctness.
--
Doug Harrison
Visual C++ MVP