Boost logo

Threads-Devel :

From: David Abrahams (dave_at_[hidden])
Date: 2006-03-06 13:41:31


Matt Hurd <matt.hurd_at_[hidden]> writes:

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

Perfectly appropriate for building on top of Boost.Threads and nothing
in Boost.Threads makes this particularly difficult. On the other hand
many of the proposals I've seen for reworking mutexes make the simple
things significantly more complicated.

  "Make the simple uses simple and make the more sophisticated uses
   possible"

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Threads-Devel list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk