Re: [boost] [thread] Use of synchronized_value<> member in a constructor

Subject: Re: [boost] [thread] Use of synchronized_value<> member in a constructor
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-06-12 16:47:54

Le 12/06/13 21:29, Klaim - Joël Lamotte a écrit :
> I am using now Boost 1.54.0 Beta (r84749).
>
> I am writting code similar to the following (but a bit more complex) :
>
> struct SequenceInfo
> {
> SequenceId id;
> ProjectId project_id;
> std::string name;
>          //....
> };
>
> class Sequence
> {
>      boost::synchronized_value<SequenceInfo> m_info;
>
> public:
>
>      explicit Sequence( SequenceId new_id, SequenceInfo info )
explicit is not needed here.
>            : m_info( std::move(info) )
>      {
>            m_info->id( new_id ); // mutex lock
You mean

           m_info->id = new_id;

?
I would define thesame kind of constructor for the class SequenceInfo .

     Sequence( SequenceId new_id, SequenceInfo info )
           : m_info( new_id, std::move(info) )
     {}

>      }
> // ...
> };
>
> My current understanding of concurrent access practice is that
> it is not necessary to use synchronization mechanisms associated to member
> objects
> manipulated into a constructor, because it can happen on only one thread.
Right.
>
> If I am correct, then the lock of the synchronized_value is unnecessary.
You don't need to lock at construction. but once constructed the lock is 
imperative.
> I suspect that there might be other cases like this one where
> the object responsable for the synchronized object should be able, rarely,
> to access the object unsafely.
For example?
>
> Suggestion: add an unsafe access to the object, in a very visible way.
>
>      m_info.unsafe_access().id( new_id );
>
> OR
>
>      m_info.unsafe_access()->id( new_id ); // using a smart pointer which
> checks if safe accesses have been done inbetween and throw if it is the
> case? or any other checks detecting potential error
I don't think this is needed for the use case presented. Just create the 
appropiated constructors.
> It looks like it would allow avoiding cost where it could be avoided using
> a mutex manipulated manually.
>
> Any thoughts on this?
I'm open to your suggestion if you have other use cases that can not be 
solved otherwise.

Best,
Vicente