On Tue, 10 Jul 2012, Tim Blechmann wrote:
great to hear ... checking the specific commit, it seems that the integration into the boost infrastructure (doc/testfarm etc) is still missing ... please compare with r79196, the specific commit for boost.lockfree.
thanks for the pointer, will fix it, and if you notice anything else, just write so I can fix it ASAP
i wonder, what is the current state of boost.atomic regarding interprocess communication?
if BOOST_ATOMIC_*_LOCK_FREE==2, then the corresponding data type is interprocess-safe
i see ... do you have any plans to provide a metafunction or traits class, which provides this information at the level of the c++ language so that it can be used for template metaprogramming?
see below, yes -- and I agree that this is helpful to have in addition to macro definitions [...]
as per the suggestion during review I have implemented a partially specialized template representing the *_LOCK_FREE macros to allow implementing an "interprocess_atomic" that is safe independent from the data type (as long as atomic_flag is safe, of course)
according to the latest draft that i have on my machine, atomic_flag shall be atomic.
True, the "difficulty" for boost::atomic is that I have provided a fallback path that is using thread::mutex as a "last resort" internally if the implementation can find no platform support at all, and this means even "atomic_flag" will use a mutex (hence not be interprocess-safe) -- this is not ideal, but the alternative is to possibly fail compilation entirely on some "fringe" platforms even for intraprocess atomics. (Of course, compilation *must* fail entirely for interprocess in such a scenario). Disagree? Regards Helge