Yes, I fully agree with your argument against

...

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

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Howard Hinnant Sent: Thursday, 22 July 2004 11:19 AM To: boost@lists.boost.org 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

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. 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