Boost logo

Boost :

Subject: Re: [boost] [atomic] interprocess (was Re: [lockfree] include into 1.51?)
From: Helge Bahmann (hcb_at_[hidden])
Date: 2012-07-10 03:41:36

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



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