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:45:53

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.

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.