Boost logo

Boost :

From: Batov, Vladimir (Vladimir.Batov_at_[hidden])
Date: 2004-07-18 17:41:45


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.


> -----Original Message-----
> From: boost-bounces_at_[hidden]
> On Behalf Of Howard Hinnant
> Sent: Sunday, 18 July 2004 2:32 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: Lock unification [move]
> I have attempted a specification of moving
> scoped_lock/read_lock/upgradable_read_lock/write_lock at:
> This is an attempt to look forward to locks+move semantics, taking
> 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:

Boost list run by bdawes at, gregod at, cpdaniel at, john at