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

On Sun, Jun 16, 2013 at 11:54 PM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:

Yes. I am thinking maybe part of the solution would be to have a second

...

optional argument in the synchronized_value<> constructor which would be lambda which would be called in the constructor body of the synchronized_value<>:

This could be added, but I don't think it is elegant.

I agree.

I was wondering if a not yet existing synchronized_value could help in your context. You would need to declare a value and a reference.

explicit Sequence( SequenceInfo info ) : m_value( info ), m_ref(M_value) { m_value.do_something(); // no need to lock.

}

It's closer to the ideal but I think it defeats the point of having only one way to access the member after the constructor is called. But the mix of this suggestion and my previous one reminded me unique_lock: you can not lock on construction with it. Maybe something similar could be done? So maybe something like that would work: explicit Sequence( SequenceInfo info ) : m_value( info , synchronized_value::dont_lock_yet ) // optional { m_value->do_something(); // don't lock! ... m_value.begin_sync(); // (random name) from here the usual locking is mandatory to access the value. m_value->do_something(); // locking } void do_something() { m_value->do_something(); // locking m_value.begin_sync(); // throw exception or UB or nothing? } I'm not sure if it would require changing the mutex concept though, but if it can be done with the current default one it would allow beginning the protection explicitly when needed but not removing it once it's active. Maybe just an atomic bool saying if the sync should happen or not, but then it's an additional test on access and with reading an atomic, which I have not a clear idea if it's expensive or not. Or maybe it would be a specialization. What do you think? Joel Lamotte