Re: CSingleLock - known behaviour?
On Wed, 25 Jun 2008 11:47:36 -0700 (PDT), malachy.moses@gmail.com wrote:
On Jun 25, 10:22?am, "Doug Harrison [MVP]" <d...@mvps.org> wrote:
On Wed, 25 Jun 2008 09:52:38 -0700 (PDT), malachy.mo...@gmail.com wrote:
Well, no. A given CSingleLock object is to be used by a single thread as an
auto (i.e. "stack") variable, and that is the correct design for lock
types. When used correctly, there is no danger of another thread messing
with the lock object, because it doesn't have access to it. The idea is for
multiple threads to call functions that protect data structures with
CSingleLock, e.g.
The CSingleLock::IsLocked() function returns the locked/signalled
state of the underlying synchronization object. See
http://msdn.microsoft.com/en-us/library/f36d0s0w(VS.71).aspx.
Unfortunately, you can't believe half of what you read in MSDN, and that's
not from the better half. The function CSingleLock::IsLocked() absolutely
does not "Determine if the object associated with the CSingleLock object is
nonsignaled", which is what it claims to do. That's just silly, and it's
obvious why if you examine the source code:
_AFXMT_INLINE BOOL (::CSingleLock::IsLocked())
{ return m_bAcquired; }
Rather, the function only indicates whether the given CSingleLock object
holds the lock; that's a subtle difference, but crucial to understand.
There
is no such concept as the locked/signalled state of the CSingleLock
object
Actually, that's pretty much the correct way of looking at it. :)
So, it indeed is entirely possible to "mess with" the state of the
underlying lock object, such as the underlying CCriticalSection.
There is no underlying "lock object"; the "lock object" is overt. It is the
CSingleLock object. The "underlying object" is the synchronization object,
in this case, the inaptly and awkwardly named "CCriticalSection". Of course
it is possible to mess with the state of the CCriticalSection; if there
weren't, there wouldn't be any point to CSingleLock!
void f()
{
? ?CSingleLock lk(mx, true);
? ?... mess with data structure
}
Multiple threads can call f(), and access to the protected data structure
is protected by the lock. Each thread creates its own lock object which
operates on the same mutex, mx.
Yes, that's true, but it's entirely beside the point that was being
made. Even though one thread will not have access to the "lk" object
created by another thread, all threads have unrestricted access to the
underlying m_cs (CCriticalSection) object, which necessarily is shared
by all of the threads. And since the m_cs object is shared by all the
threads, its state can be changed by any one of them at any time,
making the IsLocked() function irrelevant and reliance on it a source
of program logic errors.
That's because you incorrectly think IsLocked has something to do with the
mutex, and as explained earlier, it really doesn't. It indicates only
whether or not the given lock object has locked the mutex.
..BUT.. unless I am missing something - programmers should be aware of
this nasty gotcha !
Mutexes in windows are recursive; MFC Lock types are not and will assert in
debug mode if you attempt to lock a lock that is already locked. It should
be exceedingly rare to call Lock/Unlock on a lock object.
I tend to disagree with this as well. ?At least for the
CCriticalSection lock type, nested/recursive calls to lock are
perfectly permissible, and will work exactly the same as
nestedrecursive calls to the underlying CRITICAL_SECTION functions of
EnterCriticalSection and LeaveCriticalSection.
That's just plain wrong for the reason I already gave.
It's true that I misunderstood your focus on the sameness of the
CSingleLock object as opposed to that of the CCriticalSection object.
For purposes of clarity, it might be better if you did not refer to
locking of "lock types" referring to CCriticalSection::Lock() as opposed to
CSingleLock::Lock().
I thought it was clear. If I meant to refer to CCriticalSection, I would
have used that word. My only use of "Lock types" was in this context:
<q>
Mutexes in windows are recursive; MFC Lock types are not and will assert in
debug mode if you attempt to lock a lock that is already locked. It should
be exceedingly rare to call Lock/Unlock on a lock object. The vast majority
of the time, the RAII usage should be all you need, e.g.
void f()
{
CSingleLock lk(x, true); // See below.
// NB: Since I'm not quoting the "below" part, I've corrected the
// example.
...
}
</q>
I drew a distinction between mutexes and "Lock types", I went on to talk
about "lock objects", and I gave an example using CSingleLock. Nowhere did
I use the word "CCriticalSection". I don't know how to make it any clearer.
Hehe, I didn't want to spoil the fun, so it's TRUE that I didn't
answer your quiz. The answer is hopefully clear to others from a
comparison of the code you posted versus the code I posted.
We can only hope. Whenever the subject of the MFC lock types arises, I
always like to bring this up, because it's so surprising and wrong! I
expect there are numerous bugs in MT programs in the wild due to people
misunderstanding or (understandably) forgetting the necessary addition to
the initialization.
--
Doug Harrison
Visual C++ MVP