Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at