Re: [boost] Gauging interest in a thread-safe containers library

Subject: Re: [boost] Gauging interest in a thread-safe containers library
From: Frank Mori Hess (frank.hess_at_[hidden])
Date: 2009-01-14 09:33:53

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 14 January 2009 08:06 am, Mathias Gaunard wrote:
> Eric Greveson wrote:
> > I've recently been doing some work that required thread-safe
> > containers (queue, channel) and I found that in addition to these, a
> > locking_ptr with similar semantics to boost::shared_ptr (except being
> > thread-safe too)
>
> shared_ptr is already thread-safe.
> Did you mean you perform a lock around the access to the wrapped pointer?
>
> Why is it tied to shared ownership? This should be distinct things.

Yes, you could build a monitor based on a boost::optional model rather than a 
shared_ptr.  I agree it seems better to provide the monitor functionality at 
a lower level, orthogonal to shared_ptr.  That said, I too wrote a locking 
shared_ptr some time ago and as I recall the main reasons for going that way 
were:

1) Easy to support non-copyable types.  At the time, I was probably not aware 
that boost::optional supported in-place factories, but in any case shared_ptr 
supports non-copyable types in a simpler way.

2) If two threads are both accessing the same object, they will often also 
want to share ownership of the object.

I guess what I'd like to see in boost would be something like a 
boost::monitor<T> which would be like a boost::optional<T> plus monitor 
functionality, and maybe a boost::monitor_ptr<T> which would be a 
boost::shared_ptr<boost::monitor<T> > with some syntactic sugar.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFJbffU5vihyNWuA4URAmQyAKDPrHhHo94YQQ5CT1uAFgMdlu1s6QCfee3O
IFCrP2UXkt7SUBBxXXk9Sls=
=9KVQ
-----END PGP SIGNATURE-----