Re: [boost] [thread] Roadmap for RW locks ?

From: Anthony Williams (anthony_w.geo_at_[hidden])
Date: 2006-11-02 10:09:21

Howard Hinnant <hinnant_at_[hidden]> writes:

> On Nov 2, 2006, at 3:23 AM, Anthony Williams wrote:
>
>>> Agreed.
>>> So we would end up with mutex and recursive_mutex, yes?
>>
>> Yes, though I like Howard's idea of recursive_mutex being an  
>> adaptor, with
>> specializations for optimization.
>
> Btw, recursive_mutex adaptor, if it is a good idea in the first  
> place, is a good example of an application needing to lock a mutex in  
> a non-scoped manner.

Only if you allow non-scoped locking of the recursive mutex adaptor. If you
only allowed scoped locks, then the first scoped lock of the recursive mutex
can check to see if this thread owns the mutex. If so, then the whole
scoped_lock is a no-op. If not, then we need to actually lock the underlying
mutex.

template<class Mutex>
class recursive_mutex
{
private:
    Mutex m;
    thread_util::id id;
public:
    recursive_mutex():
        id(thread_util::not_any_thread())
    {}

    class scoped_lock
    {
        recursive_mutex& m;
        std::auto_ptr<typename Mutex::scoped_lock> lock;
    public:
        scoped_lock(recursive_mutex& m_):
            m(m_)
        {
            if(m.id!=thread_util::self()) // assume atomic read
            {
                lock.reset(new typename Mutex::scoped_lock(m.m));
                m.id=thread_util::self();
            }
        }
        ~scoped_lock()
        {
            if(lock.get())
            {
                m.id=thread_util::not_any_thread();
            }
        }
    };
};

> Ion pointed out to me that recursive_mutex shouldn't hold a mutex&,  
> but rather a mutex.  

Yes. I always assumed it would be a type adaptor, not an instance adaptor.

> I should also stress:  recursive_mutex is an experiment, not a  
> proposed solution.  I'm just thinking out loud, and would like more  
> help in the thinking department. :-)

Well, my Windows implementation of a recursive mutex is essentially just an
adaptor on boost::mutex, so your thinking coincides with mine.

>> I was thinking about mutex,
>> try_mutex and timed_mutex, which I think can really be one and the  
>> same
>> class.
>
> I've also been experimenting with a timed_mutex adaptor:

[snipped example impl]

Intriguing thought. It's certainly doable, and can also be specialized to
allow for optimization where the adapted mutex is already timed-capable.

> This is even less mature than the recursive_mutex.  But hopefully  
> people can see where I'm trying to go:  Instead of having recursive  
> and timed flavors of every kind of mutex (exclusive, sharable,  
> upgradable), one might instead have adaptors that one could apply to  
> these, and perhaps to user-defined mutexes as well (more motivation  
> for mutex concepts: here's more generic mutex code people could plug  
> into).

I like the idea of providing adaptors so that behaviour can be added to basic
mutexes. Maybe some traits or Concepts could be used to mean that people
didn't have to explicitly specialize timed_mutex_adaptor<custom_mutex> if
custom_mutex already supported timed locks. 

Your sample adaptor has given me the idea of not having an explicit timed_lock
function, but rather overloads of try_lock:

bool try_lock(); // just try once
bool try_lock(unsigned spin_count); // spin this many times
bool try_lock(target_time_type target_time); // wait until the specified time
bool try_lock(time_period_type wait_time); // wait for the specified period

Anthony
-- 
Anthony Williams
Software Developer
Just Software Solutions Ltd
http://www.justsoftwaresolutions.co.uk