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