Re: CSingleLock - known behaviour?
On Wed, 25 Jun 2008 15:39:07 -0400, Joseph M. Newcomer
<newcomer@flounder.com> wrote:
See below....
On Wed, 25 Jun 2008 13:00:16 -0500, "Doug Harrison [MVP]" <dsh@mvps.org> wrote:
The real mistake is that you can pass a dwTimeOut value != INFINITE when
locking a CCriticalSection.
****
The Lock code for CCriticalSection has an ASSERT
ASSERT(dwTimeout == INFINITE);
Of course, in release mode, this will fail to detect an erroneous call.
****
Yeah, I know. As I recall, the CMultiLock class also asserts when passed a
CCriticalSection. It's just really bad design. And while this isn't
entirely MFC's fault, even the name "CCriticalSection" grates, because a
"critical section" is a region of code, not a data type, and the Windows
CRITICAL_SECTION object is really a type of lightweight mutex. In fact,
that's what I call it in my class library, "LwMutex". The MFC
synchronization classes have always bugged me for these and many other
reasons, literally from the moment they were introduced, I guess it was in
VC4. I continued to use and write my own synchronization classes rather
than use the MFC ones, which have always been rather hopeless.
As I explained in my messages, while the MFC sync classes are bad, there's
nothing wrong with the non-recursive nature of the lock class. If you
really believe there is, present an example that would take advantage of a
recursive lock class. I expect it will demonstrate poor design.
****
A named mutex used in two different processes; a named event used in two different
processes; a semaphore that is in a loop that needs to decrement the semaphore until it
blocks; that's just the start. Note that CMutex, CSemaphore, and CEvent all allow the
name to be supplied and used, but you can't actually use the primitives across processes.
I don't see how any of that is relevant to the use of CSingleLock.
Seriously, try to write some code that exploits a recursive CSingleLock.
And what is wrong with the non-recursive nature of the lock is that the OP appears to have
a legitimate reason to need recursive acquisition, and it doesn't work.
I can't imagine good code that needs a recursive CSingleLock. Code example,
please?
And no, it doesn't say anywhere in the discussion of CSingleLock class that it violates
the basic principles of recursive acquisition and cannot be used in that way
Yeah, well, you're talking about MSDN, and you know what you think about
MSDN. :)
or that it
cannot be used when the object is shared between processes
If by "object" you mean (for example) CMutex, and thus kernel-based mutex,
I'm unaware of any such restriction.
and the documentation of
CSingleLock::Lock is deficient in the same way, nor does it say that the timeout must be
INFINITE for CCriticalSection. Furthermore, the discussion of the class does not mention
the existence, let alone the use, of CSingleLock::Lock, and the example is erroneous in
that it sets the lock and doesn't check the result, but then checks the IsLocked variable,
which sets up a potential race condition.
Are you talking about this example?
CSingleLock::IsLocked
http://msdn.microsoft.com/en-us/library/f36d0s0w(VS.80).aspx
<q>
CSingleLock singleLock(&m_Mutex);
// Attempt to lock the shared resource
singleLock.Lock(100); // Wait 100 ms...
// Has the resource been successfully locked?
if (singleLock.IsLocked())
{
// We were able to lock the resource;
// we may now work with the data associated with the mutex...
// Now that we are finished, unlock the resource for others.
singleLock.Unlock();
}
</q>
It doesn't need to check the result of Lock, because it calls IsLocked, and
there is no race, because CSingleLock::IsLocked is implemented as follows,
and the CSingleLock object is an auto (local stack) object, so every thread
running the code gets its own CSingleLock:
<q>
_AFXMT_INLINE BOOL (::CSingleLock::IsLocked())
{ return m_bAcquired; }
</q>
Or that the destructor will unlock the
object, making it unusable when using CSemaphore. What can possibly be *right* about
these classes?
joe
Not much. :)
--
Doug Harrison
Visual C++ MVP