Dave Butenhof says it all:
"A READ lock guard object construct can be a great boon -- it adds
convenience with no real risk.
"A WRITE lock (or normal mutex) guard object introduces substantial risk
of its own because it'll unlock implicitly when the destructor fires no
matter what the cause or where in the code the unwind occurred. An
unlock with broken shared data predicates is a serious bug, and the
guard object can make the bug really hard to find. Obviously this risk
can be controlled -- but it's not trivial for beginners.
"Whereas 'straight C style' code [...] is more likely to exit still
holding the lock. Also bad, clearly; but generally much easier to
diagnose. Any decent lock analysis package will be able to tell you
where the lock was taken after it leads to deadlock, and the state of
the data will be available for analysis. No analysis package is going to
be able to tell you where your guard implicitly released a lock when it
shouldn't have.
"Guard object are 'cool', and quite often appropriate and convenient.
But they can also be extremely dangerous if not completely understood."
[http://groups.google.com/group/comp.programming.threads/browse_frm/thread/da3250ad80685b3b/5be7024ff5873a09]
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
