On Wed, Jul 30, 2014 at 1:51 AM, Klaim - Joël Lamotte
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.