Boost logo

Boost :

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-07-07 08:19:31

Peter Dimov wrote:
> Howard Hinnant wrote:
>>I like the latent_write_lock / upgradeable lock idea proposed by Bruno
>>/ Alexander. I have been playing with the following interface:
>>namespace detail
>>template <class RW_Mutex>
>>class read_lock
>> typedef RW_Mutex mutex_type;
>> explicit read_lock(mutex_type& m, bool lock_it = true);
>> explicit read_lock(upgradable_read_lock<mutex_type>& r);
>> explicit read_lock(write_lock<mutex_type>& w);
>> ~read_lock();
>> void lock();
>> bool try_lock();
>> void unlock();
>> bool locked() const;
>> operator int bool_type::* () const;
>> read_lock(const read_lock&);
>> read_lock& operator=(const read_lock&);
> [...]
> Seems very good to me. Also demonstrates a better lock taxonomy

Better compared to what? The current read/write lock taxonomy? One of
the many suggestions in this discussion?

> (which
> allows me to include some on-topic content ;-) ):
> Lock
> Lock( Mutex&, bool = true );
> void lock();
> void unlock();
> bool locked() const;
> operator int bool_type::* () const;
> TryLock: Lock
> +bool try_lock();
> TimedLock: TryLock
> +bool timed_lock( xtime const & );

The point being that TryLock is a refinement of Lock, and TimedLock is a
refinement of TryLock? If so, I agree that's better than TryLock and
TimedLock both refining Lock. There are still the constructor issues to
deal with in such a lock taxonomy, however. The main one: how do you
define destructors that are consistent within a lock concept and also
consistent between concepts. E.g., on the one hand it seems that a
one-parameter constructor should do the same thing in all lock types--so
it would have to block; on the other hand, it seems that TryLock
constructors should not block unless instructed to do otherwise.


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