Re: [boost] [thread] synchronized_value: value and move semantics

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

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;

Just a thought.