Re: [Threads-devel] Mutexes

From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2006-03-06 12:43:40

>On Tuesday 07 March 2006 02:30, David Abrahams wrote:
<snip>
> I haven't seen a single example that demonstrates why the current
> interface is deficient, and in fact all the alternative proposals have
> clear disadvantages in verbosity and complexity.
OK.  Let's get concrete and look at a use case.

//-----------------------------------
struct fragile
{
    void set( const some_data& sd)
    {
        lock lk(guard_);
        sd_ = sd;
    }
    
    some_data get() const
    {
        lock lk(guard_);
        return sd_;
    }
    
    //payload
    some_data sd_;
    
    //protection
    typedef boost::mutex::scoped_lock lock;
    mutable boost::mutex guard_;
};
//-----------------------------------
Shows the current nice clean boost.thread interface.  The current boost.thread 
works well for such a simple case.

My alternative is to enable the struct fragile to be with or without 
concurrency support in addition to supporting shareable or exclusive access.

I have definitions for synch::no_synch, synch::simple, synch::shareable (as 
well as a synch::recursive) to support this approach:

//-----------------------------------
template < class S = synch::no_synch >
struct fragile2
{
    void set( const some_data& sd)
    {
        lock lk(guard_);
        sd_ = sd;
    }
    
    some_data get() const
    {
        lock lk(guard_, synch::lock_status::shared);
        return sd_;
    }
    
    //payload
    some_data sd_;
    
    //protection
    typedef typename S::lock lock;
    mutable typename S::mutex guard_;
};
//-----------------------------------

Now fragile is parameterised for concurrency with a simple don't pay for what 
you don't use approach.

You code to synch::shareable and then synch::simple and synch::no_synch is 
also available.  Shared access is demoted to exclusive for types not 
supporting it.  synch::no_synch just optimizes the whole kit away.

Your thoughts?

Matt.