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
> 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
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk