Re: CSingleLock - known behaviour?
On Wed, 25 Jun 2008 14:03:12 -0700 (PDT), neilsolent
<neil@solenttechnology.co.uk> wrote:
Wow this has caused a stir !
Good posts.
My comments are:
1. Someone raised the point "I think it would be very strange for you
to logically not know whether or not a Lock object is locked or not. "
That was me.
My answer: Of course I know whether a lock object is locked or not -
or at least I could code in that way - but I was writing my code based
on the assumption that it didn't matter whether the CSingleLock object
had already had Lock() called on it previously - I made the assumption
that the underlying MFC code would handle this intelligently. If you
don't have to keep checking the state of your locks, you can write
simpler, neater code that is easier to read and maintain.
I've used lock classes extensively for 10+ years, and I can't recall ever
needing to use a function such as CSingleLock::IsLocked, nor can I recall
coding myself into contortions to avoid it. Can you give me an example or
two that demonstrates why you need to do this?
2. I think the CSingleLock::IsLocked() function tests whether Lock()
has been called successfully - NOT whether the underlying
synchronisation object has been locked by a different thread. From
some of the posts it sounds like people disagree..
You are correct. Someone introduced the mistaken notion several messages
ago, and I corrected this misunderstanding in my reply.
3. I am now using this function in place of CSingleLock::Lock()
directly, and everything is working for me:
void SafeLock(CSingleLock& lock)
{
if (! lock.IsLocked()) lock.Lock();
}
Please don't take this the wrong way, but if you need to do that on
anything but an exceedingly rare basis, I'd have to suspect you're using
CSingleLock in less than an optimal fashion. It makes me wonder if you're
using a CSingleLock as a class member, or you're passing CSingleLock by
reference from function to function, etc, which would almost certainly
represent invalid use of this class for the "critical section" object you
mentioned in your first message.
--
Doug Harrison
Visual C++ MVP