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.