🚀 go-pugleaf

Webb Scales wrote:
> 
> David Brownell wrote:
> > One of the really nice techniques is to have a "Locker"
> > class to grab mutexes
> > as needed, and then release it automatically on all exits.  [...]
> > That kind of class really helps get rid of the bugs you have due
> > to locks not getting released uniformly on all codepaths.
> 
> Hmmm...this approach makes me nervous.  I assert that it's better
> to neglect to unlock a mutex than to unlock it when you shouldn't have.

Depends on how you're using the mutex; both bugs are deadly.  Did the
victim die because of the loss of blood first, or the kidney failure?
(Don't you just hate it when police beat up suspects?)


> For instance, if a thread holding a mutex via the "Locker" class terminates
> prematurely (due to an exception or cancellation), then the mutex will be
> unlocked automagically, despite the fact that whatever it was supposed to
> protect is now likely to be in an inconsistent state.

Huh???  What kind of buggy algorithm are you assuming?

Cleanup processing for exceptions/cancellation is required to leave
the resources in a consistent state ... else the cleanup processing
is buggy.  The ** whole point ** of the cleanup processing (destructor
handling etc) is to keep state consistent.  Any C++ instructor who is
not making this clear needs to be immediately replaced.

Now ... given that C++ stack cleanup is done on each function call
exit, and hence isn't specific to exceptions/cancellation, I'd claim
that bugs in cleanup with a "Locker" class are found VERY fast.  I
can support that with my own experience, FWIW!


> The missing piece is that the destructor for Locker, prior to releasing the
> mutex, must restore the shared data that the mutex protects to a consistent
> state.  In order to do this, the destructor requires intimate knowledge
> of what the lock is protecting -- this invalidates the "generic" approach.

Well, I never said that you would _only_ have a "Locker" class!  I called
it a _technique_ ... meaning, "modify as appropriate".  You're talking as
if I'd said "here's a complete general purpose library", which I didn't.
I'd claim there is no such critter, in fact.

Typical programming style for mutexes is that functions have an
invariant:  the mutex state doesn't change as a consequence of calling
the function.  The "Locker" class I posted did that just for mutexes,
since that generalizes naturally and is an appropriate starting point
for such discussions.

More complex invariants can be encapsulated in other classes rather
easily, and should be.  As in fact Webb noted later.  I didn't have time
to write out a complete C++/MT style guide; that point is a logical
combination of (a) encapsulation, and (b) the "Locker" technique.

- Dave