Re: [boost] [atomic] interprocess (was Re: [lockfree] include into 1.51?)

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 
scenario).

Disagree?

Regards
Helge