Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk