Re: CSingleLock - known behaviour?
On Wed, 25 Jun 2008 13:47:04 -0400, Joseph M. Newcomer
CSingleLock and all the MFC locking classes are complete crap, and should be avoided.
While a CRITICAL_SECTION has recursive acquisition semantics, the MFC layers introduce so
many bugs that it would not at all surprise me if CCriticalSection was as bug-laden as the
rest of the code.
Don't call IsLocked, it won't help, and in fact will produce an erroneous result. The
correct solution is to never, ever use an MFC locking primitive under any conditions.
P.S. I decided to check, and indeed, the moron who wrote the code got something this
simple wrong also! Here's the code:
BOOL CSingleLock::Lock(DWORD dwTimeOut /* = INFINITE */)
ASSERT(m_pObject != NULL || m_hObject != NULL);
m_bAcquired = m_pObject->Lock(dwTimeOut);
Note how this ASSUMES that it is an error to do a recursive acquisition!!!!!
The real mistake is that you can pass a dwTimeOut value != INFINITE when
locking a CCriticalSection.
It takes a
profound amount of either stupidity or irresponsibility to create a primitive that
violates the fundamental behavior of the underlying object, which this CAREFULLY goes out
of its way to accomplish.
Now look at the unlock code:
ASSERT(m_pObject != NULL);
m_bAcquired = !m_pObject->Unlock();
// successfully unlocking means it isn't acquired
Note how the programmer, who clearly knew NOTHING about locks, wrote the code! It will
only do an unlock if it believes the lock is set, and the result of a successful unlock is
to clear the lock flag, so the second unlock cannot possibly work!
Further proof that whoever wrote this had NO understanding of synchronization,
concurrency, or fundamental principles of software design, and had NO adult supervision.
This code makes no sense; it doesn't make sense for a critical section, mutex, semaphore,
or event. It cannot be made to make sense. It is wrong.
It just confirms that these classes are complete and utter wastes of space.
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.
Visual C++ MVP