Howard, Thank you for your time to get the spec. together. A must to move forward. A few comments. 1. explicit scoped_lock(mutex_type& m); 2. scoped_lock(mutex_type& m, locking_enum lock_it); 3. scoped_lock(mutex_type& m, blocking_enum block_it); 4. scoped_lock(mutex_type& m, const elapsed_time& elps_time); Do we need (3)? Isn't is covered by (4) with elps_time = INFINITE (blocking) and - 0 (non blocking)? If it is intended as a "convenience" interface, my expectation would be that average users would use thin and more explicit wrappers around the general lock. Like try_lock and timed_lock. Then, those thin wrappers would address the "convenience" issue better. (1) and (2) overlap as (1) is (2) with lock_it = true. Does not it mean that some functionality will have to be duplicated in (1) and (2)? How about avoiding the overlap with 1. explicit scoped_lock(mutex_type& m); 2. scoped_lock(mutex_type& m, deferred_t); Then, every constructor would do just one thing. My 2c. Best, V.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Howard Hinnant Sent: Sunday, 18 July 2004 2:32 PM To: boost@lists.boost.org Subject: [boost] Re: Lock unification [move]
I have attempted a specification of moving scoped_lock/read_lock/upgradable_read_lock/write_lock at:
http://home.twcny.rr.com/hinnant/cpp_extensions/threads.html
This is an attempt to look forward to locks+move semantics, taking into account the recent discussions. Because of the length of the specification I put it in an html on my personal website instead of stuffing it into an email. Comments welcome. Any response from me is likely to be delayed by several days due to travel.
-Howard
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost