[boost] Repost: Lock Classes

From: Kevin Atkinson (kevin_at_[hidden])
Date: 2003-02-28 18:50:58

This is a repost of my Lock Classes.  Hopefully this time I will get some
constructive feedback. These classes have the following features.

  1) The ability to acquire a lock and release it when the object
     goes out of scope effectively implemented the "Monitor" concept.
  
  2) Avoid the need for recursive locks by careful and efficient
     book keeping with the out the use of global thread specific
     data.
  
  3) Document and enforce guaranteed lock behavior for functions
     which take a lock class as a parameter.

Recursive locks may avoid the need for the bookkeeping.  However recursive
looks are more expensive.  Also, with recursive locks, as far as I know,
it is imposable to temporally release the lock.  For example when calling
a network function I don't want to keep the lock as the object is in a
consistent state and holding the lock while waiting for a reply will
greatly reduce concurrency.  My lock classes makes this possible to do
efficiently and safely as it is not possible to accentually call a
function that will release a lock without giving it permission to do so.

The only downside is that you have to explicit pass the lock around to
each function as a parameter.  My recommendation is to use the lock
classes as parameters to private methods or functions which may call each
other and thus need to avoid acquiring a non recursive lock more than
once.  Public members can than call the private members by simply 
providing the function with the appropriate lock.

I have not seen anything quite like it so I thought I would share it here 
and see what other people think. 

Feedback on the idea or implementation welcome.  This code, at the moment, 
does not follow boost standards.  If people think it is a worthy addition 
to boost I will be willing to being it up to boost standards.  But for 
right now please refrain from making comments on coding style or the 
like.

Changed from first post:
  Used a dummy Mutex class as the implementation is unimportant
  Added macros for using the lock classes for the current scope
    after learning the hard way that "Lock l0(l)" is a bad idea.  
    See code for details
-- 
http://kevin.atkinson.dhs.org