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