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

Subject: Re: [boost] [thread] Use of synchronized_value<> member in a constructor
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2013-06-16 19:36:38

On Sun, Jun 16, 2013 at 11:54 PM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> 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<T&> 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