Boost logo

Boost :

Subject: Re: [boost] [thread] synchronized_value: value and move semantics
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-06-26 15:58:31


On Wednesday 26 June 2013 23:56:27 you wrote:
> On Wednesday 26 June 2013 15:39:27 you wrote:
> > On Wed, Feb 20, 2013 at 10:02 PM, Vicente J. Botet Escriba <
> >
> > vicente.botet_at_[hidden]> wrote:
> > > Hi,
> > >
> > > boost::synchronized_value (not released yet [1][2][3]) is based on [4].
> > > See below part of this paper adapted to the Boost.Thread interface.
> > >
> > > Currently boost::synchronized_value is in addition Copyable and
> > > Swappable.
> > > I was wondering if it is worth adding value and move semantics to
> > > synchronized_value. Making it EqualityComparable, LessThanComparable and
> > > Movable if the underlying type satisfy these requirements will allow to
> > > store them on a Boost.Container/C++11 container.
> > >
> > > Do you see something completely wrong with this addition?
> > > Has some of you had a need for this? Could you share the context?
> >
> > Sorry, I missed this discussion somehow. I've taken a quick look at the
> > interface and have a few questions:
> >
> > 1. Why are there strict_lock_ptr and unique_lock_ptr? What are the
> > differences and why we can't have one such ptr (presumably,
> > unique_lock_ptr)?
> > 2. I find value() and get() a bit confusing, since it is not apparent what
> > is the difference between them. Maybe value() could be renamed to
> > get_ref()
> > or unsafe_get()?
> > 3. Am I correct that having strict_lock_ptr/unique_lock_ptr acquired by
> > calling synchronize() will not deadlock with operator-> when a
> > non-recursive mutex is used?
>
> Also, if it's not too late yet:
>
> 4. Could synchronized_value be renamed to just synchronized? Besides being
> shorter, this naming seems to be aligned with optional and reads more
> naturally. Consider:
>
> optional< int > oi;
> synchronized< queue< int > > sqi;
>

...and also atomic:

  atomic< int > ai;


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