Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

dwTimeout parameter in CCriticalSection::Lock()

434 views
Skip to first unread message

WJ

unread,
Jan 11, 2010, 11:28:01 AM1/11/10
to
I'm using CSingleLock to lock a critical section and pass a timeout (10
seconds) when I call CSingleLock::Lock.

A ASSERT fails at run time and I see that in CCriticalSection::Lock() the
dwTimeout is not used, and it asserts the dwTimeout must be INFINITE.

why CCriticalSection::Lock() does not take a timeout other than INFINITE?
Thanks.

WJ

Joseph M. Newcomer

unread,
Jan 11, 2010, 11:47:23 AM1/11/10
to
I am absolutely certain that the code does not take "A" ASSERT. In my experience, it
always takes an assertion on a specific line of a specific file, neither of which you
thought was important enough to mention. You also did not say what version of VS you are
using.

You apparently neglected to notice that CCriticalSection cannot under any circumstances
have a non-INFINITE timeout. This is because it is a wrapper around CRITICAL_SECTION,
which cannot have a timeout.

But then, the MFC synchronization primitives are so badly designed as to be beneath
contempt. They were clearly designed by someone who knew nothing about synchronization,
and it is hard to take them seriously.
joe

Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Goran

unread,
Jan 12, 2010, 4:30:27 AM1/12/10
to

Because CCriticalSection is a wrapper around critical section API, and
that API has no timeouts (relevant functions: TryEnterCriticalSection,
EnterCriticalSection.

CCriticalSection derives from CSyncObject, who declares virtual Lock
as having a timeout. So CCriticalSection inherits that, but can't work
with a timeout. This is a clear-cut violation of a so-called Liskov
substitution principle. I think, among CSyncObjects derivatives,
CCriticalSection is the only one that can't handle that timeout
parameter.

This is an architectural bug in MFC. There could have been
CSyncObjectWithTimeout where Lock would have a timeout., e.g.

CSyncObject
| |
CCriticalSection CSyncObjectWithTimeout
|
CEvent, CMutex...

Then, one could have void Lock() in CSyncObject and bool Lock(DWORD
timeout) in CSyncObjectWithTimeout. CSingleLock could then have ctors
CSingleLock(CSyncObject&) (uses Lock with no timeout) and CSingleLock
(CSyncObjectWithTimeout&, DWORD). (CSingleLock should never have had
Lock and Unlock methods, only ctor and dtor; Lock and Unlock is
__not__ how such classes are made).

Goran.

0 new messages