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
>>{
>>public:
>> 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;
>>
>>private:
>> 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.
Mike