Re: [boost] Fwd: [sync?] "Distributed" value (or something...)

Subject: Re: [boost] Fwd: [sync?] "Distributed" value (or something...)
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-07-30 04:47:12

On Wed, Jul 30, 2014 at 12:45 PM, Andrey Semashev
<andrey.semashev_at_[hidden]> wrote:
> On Wed, Jul 30, 2014 at 1:51 AM, Klaim - Joël Lamotte <mjklaim_at_[hidden]> wrote:
>>
>> I would like to ask Boost developers and users:
>>
>>  1. Am I the only one seeing the following pattern in my concurrent systems
>> code?
>>  2. Is there already some tools available in Boost that does what I
>> describe here and that I am not aware of?
>>  3. If not, would there be any interest in the tool I'm describing here or
>> not? Is it a dumb idea?
>>  (I keep getting back to this idea but I'm surprised not finding anything
>> similar online)
>>
>>
>> The pattern that I am seeing occurs when:
>>  1. I have a value or a set of values in an object or several objects which
>> value(s) describe some kind of configuration that several other systems
>> will read and use.
>>  2. The object(s) will be updated only by one thread (at a time).
>>  3. When the object's value is modified, all the systems that rely on the
>> object's value have to be notified
>>     so that they update themselves using that value.
>>  4. The systems I am refering to can use different threads for updating and
>> we can assume that they are running concurrently.
>>  5. It is not important that the source object's value is synched with the
>> reader's values at all time,
>>     however it is important that the sequence of changes to the source
>> object's value is signaled to the readers
>>     exactly in the same order and "as fast as possible", but delay is ok.
>
> I'm not sure I fully understood the idea but is it implementable in
> RCU manner? I think you can have a mutex-protected shared_ptr to the
> value, which every reader can obtain and use. When the reader is not
> using the value it demotes it to weak_ptr. Next time the reader wants
> to use the object it attempts to promote it to shared_ptr, which will
> only succeed if the value has expired.

Read that as "has not expired".

> This approach does not involve any callbacks, which might be a good or
> bad thing depending on the use case. In any case, I think this would
> be a fairly high level primitive (especially if async callbacks are
> involved), so I'm not sure Boost.Sync is the right place for it.