Re: CSingleLock same-thread double-access problem.
On Thu, 27 Sep 2007 11:18:03 +0200, "Ricardo Vazquez" <rvazquez@dummy.com>
wrote:
Mixing them all up, I've finally come up to mend then use this "unedited"
class I found at CodeProject:
http://www.codeproject.com/useritems/CustomCriticalSection.asp
Adding the Sasa Reskovic fix, it achieves exactly what I was looking for:
Re-entrant call to "lock", that manages what Doug Harrison called "composite
operations for which the entire sequence of operations must be locked".
I haven't looked at that class, but Windows mutexes support recursive
locking at the OS level; you don't need a class for that. The only way this
can help with operation sequences on a class X is if X exposes the mutex or
locking functions, such that users of X can lock/unlock around the entire
sequence, in the same way that the X member functions do. This is more a
quick and dirty solution to the problem than a well-engineered one, and
it's subject to performance degradation inside a protected sequence due to
unnecessary locking by the individual member functions of X. Unless a
thread-unsafe version of the class makes no sense at all, I'd be tempted to
just leave the class thread-unsafe and leave it up to users to perform
their own locking, on an as-needed basis. For example, that's what STL
containers do. Alternatively, you could have two APIs, a "normal" API that
performs locking and a "nolock" API that does not; you would also need to
expose the lock/unlock functions so that the "locking API" and the "nolock
users" use the same mutex. For example, MS has done this for stdio in the
latest version of the compiler, and it accomplishes two goals:
1. It allows users of the CRT DLL, which is only multithreaded, to get much
better performance by avoiding locking in single threaded code. This can
really help when using byte functions like fgetc in a tight loop.
2. It helps people write composite operations that are atomic WRT other
operations on the same file.
--
Doug Harrison
Visual C++ MVP