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

From: Batov, Vladimir (Vladimir.Batov_at_[hidden])
Date: 2004-07-21 20:59:17

Yes, I fully agree with your argument against 

>> basic_lock(mutex_type&, const elapsed_time&, defer_type);

That suggestion was OTOH and clearly messy and bad. Although the point I
tried to make was that the interface appeared somewhat inconsistent -- I
can create a deferred blocking lock but not a deferred "try" lock.
However, I now clearly see that I was thinking in terms of separate
classes "scoped, try, timed". That is not true anymore. After thinking
about it some more (I know, I should have done it from the start :-) ),
I like the proposed interface. Essentially,

scoped_lock(mutex_type& m, detail::defer_lock_type);

is a constructor in its own right as (unlike the other three) it does
not create a specific (blocking, try, timed) lock. The more I think
about it, the more I like it.

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]]
> On Behalf Of Howard Hinnant
> Sent: Thursday, 22 July 2004 11:19 AM
> To: boost_at_[hidden]
> Subject: [boost] Re: Lock unification [move]
> 
> On Jul 21, 2004, at 7:16 PM, Batov, Vladimir wrote:
> 
> > Howard,
> >
> > Thank you for taking on the task of shaping up the interface. That
> > activity is of great importance. A few comments.
> >
> >     explicit scoped_lock(mutex_type& m);
> >     scoped_lock(mutex_type& m, detail::defer_lock_type);
> >     scoped_lock(mutex_type& m, detail::try_lock_type);
> >     scoped_lock(mutex_type& m, const elapsed_time& elps_time);
> >
> > The problem (as I can see it) with the set above is that "deferred",
> > "tried" and "timed" appear to be alternatives or mutually exclusive.
> > However, "deferred" and, say, "try" functionalities are orthogonal.
> > That
> > is, as one might need to defer a blocking lock
> >
> >     scoped_lock l(m, deferred);
> >
> > one might need a deferred try_lock as well. Therefore, as we are
trying
> > to provide one universal lock, it appears we have to have something
> > complex like
> >
> >     basic_lock(mutex_type&, const elapsed_time&, defer_type);
> >
> > that would address all the lock variability/configurability.
> 
> I'm not seeing that the combination of time and defer always make
sense:
> 
> time         defer           description
> ---------------------------------------------------
> 0             yes            interpret as don't lock
> 0             no             interpret as try-lock
> finite        yes            no interpretation
> finite        no             lock if you can get it in time
> infinite      yes            no interpretation
> infinite      no             interpret as lock
> 
> Some of the combinations don't appear to have clear meanings.
> 
> Even more importantly, the underlying mutex might not support time.
> Below is a list of mutex functionality that I have so far identified
in
> the spec.  Recursion is ignored for this discussion (it isn't relevant
> to locks, and thus not relevant to mutex interface, only to mutex
> implementation details):
> 
> Mutex interface:
> ----------------
> 
> void lock();
> void unlock();
> 
> bool try_lock();
> 
> bool timed_lock(const elapsed_time&);
> 
> void lock_sharable();
> void unlock_sharable();
> 
> bool try_lock_sharable();
> 
> bool timed_lock_sharable(const elapsed_time&);
> 
> void lock_upgradable();
> void unlock_upgradable();
> 
> bool try_lock_upgradable();
> 
> bool timed_lock_upgradable(const elapsed_time&);
> 
> void unlock_and_lock_sharable();
> 
> void unlock_and_lock_upgradable();
> void unlock_upgradable_and_lock();
> 
> void try_unlock_upgradable_and_lock();
> 
> The spaces between signatures are relevant.  They represent groupings
> where I believe it is reasonable for a mutex to support a group of
> signatures, but exclude other groups.  For example, it is very
> reasonable for a mutex to support lock and unlock but not try_lock.
Or
> perhaps lock, unlock and try_lock, but not timed_lock.  If a lock
> constructor forces the semantics of "deferred lock" to call
> m_.timed_lock(elps_time), then a compile time error results if the
> mutex does not support timed_lock(), even though timed_lock isn't
> needed to support "deferred lock" (no mutex interface is required to
> support deferred lock).  So I'm very reluctant to have a lock function
> that calls two mutex functions that can reasonably be expected to not
> be implemented in the same mutex.
> 
> -Howard
> 
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost