[boost] Re: Lock unification [move]

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2004-07-24 11:26:00

Ok, new spec up at:

http://home.twcny.rr.com/hinnant/cpp_extensions/threads.html

Summary of changes:

I had messed up copy semantics with sharable and upgradable locks.  I 
don't believe copy semantics of these locks is warranted.  All of the 
locks are now movable only.  And conversions among the locks are 
limited to demotion from an rvalue, with the exception of 
upgradable->scoped.  There is now a conversion summary section for a 
quick overview.

Fixed the recursion bug pointed out by Eric (I think).  I've looked 
over this point with respect to the sharable and upgradable assignment 
operators as well.

try_move has been dumped in favor of overloaded |= and <<= operators.  
This does not mean that I'm set on these operators, or that ~= or %= 
wouldn't be better as Rob suggests.  Just there were getting to be so 
many changes, I wanted to get a new spec up.

I've added a new section:  Summary of mutex operations, which describes 
each mutex function.  Those lock functions that call a mutex function 
link into this section.  Each mutex function is labeled "blocking" or 
"not blocking" as appropriate.

The spec does not yet reflect Bronek's lock_base suggestion.  
Personally I'm still mulling that over.

The spec still contains the debated "try-lock" constructors (and an 
additional one in fact: try-upgradable->scoped construction), and the 
spelling of the object tags is still defer_lock and try_lock.

I don't intend for this to be the only spec considered.  It might be 
beneficial for there to be several competing specs that we can easily 
compare against one another (maybe a spec that doesn't try to do move?) 
  But I'm not volunteering to write an alternative spec at the moment. 
;-)  Fwiw, I'm continuing to back this spec with a prototype 
implementation so that I can have at least some confidence in what I'm 
writing.

-Howard