RE: [boost] Re: Lock unification [move]

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

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_at_[hidden]
[mailto: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:
> 
> 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