Andrew John Hughes wrote:
2009/9/21 Daniel D. Daugherty <[email protected]>:
Andrew John Hughes wrote:
Assuming your analysis of the locking is correct (it sounds that way
to me), then this seems like a fairly straightforward patch.
So far no one has found any holes in the logic :-) But then again it
took a few years to find this one :-)
Concurrency problems tend to be like that. Code like this can be
difficult to get right, and still far too few people are even taught
good practice, never mind using it.
MutexLocker seems to make things especially interesting, as there is
no explicit unlock call, it just happens as a side-effect of the
instance leaving scope and the destructor being called.
I guess I would argue that there is no explicit lock call either.
That's the beauty of the helper object pattern. You allocate the
helper object for the scope in which you need to hold the lock.
No more. No less. No more forgetting to unlock. No more matching
of lock and unlock calls.
Dan
