Re: [atomic] Bikeshedding over address-free waiting/notifying operation names

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2020-06-02 15:37:51

On 2020-06-02 17:28, Hans Dembinski via Boost wrote:
> 
> 
>> On 2. Jun 2020, at 11:21, Alexander Grund via Boost <boost_at_[hidden]> wrote:
>>
>>
>>>> boost::interprocess::atomic.
>>>
>>> That name cannot be used in Boost.Atomic as it is reserved for Boost.Interprocess.
>>>
>>> Atomics that are lock-free can already be used for inter-process communication, so a hypothetical boost::interprocess::atomic would largely duplicate boost::atomic. However, I'm open to the idea, if it is significantly different from boost::atomic.
>>
>> The obvious solution then is to use boost::atomic::interprocess ;-)
> 
> ... I was going to suggest the same :)

The problem with this is that the resulting name will be long and have 
the potential of name clash with Boost.Interprocess.

Boost.Atomic types are currently defined in namespace boost::atomics and 
then imported into namespace boost (so that people can use 
boost::atomic<int> instead of boost::atomics::atomic<int>). Adding 
namespace boost::atomics::interprocess would make it impossible to 
import it into namespace boost as it would conflict with 
Boost.Interprocess. So people will have to spell 
boost::atomics::interprocess::atomic<int>, which is unfortunate.

There is an alternative to name the type differently, e.g. 
boost::atomics::interprocess_atomic<int> or 
boost::atomics::pshared_atomic<int>, though I'm not sure I like it 
either. Or use a different name for the nested namespace instead of 
interprocess (ipc? other suggestions?).

>> I do see value in having 2 different atomic types in different namespaces as the use case is different:
>> The "regular" atomic usually works. Once you need interprocess communication you use another type, not another member function.
> 
> Agreed, having two different types has benefits:
> - you can prevent people to pass a boost::atomic where a boost::atomic::interprocess is needed (if that makes any sense..., do atomics ever appear in interfaces?)
> - you can make the intent clear in the implementation of a class or function

Yes, I can see the potential benefit of having a separate type for 
inter-process. That would allow writing generic algorithms over 
process-local and inter-process atomics. It's those naming details I'm 
not quite happy about.

Also, and more importantly, given that atomics may potentially use 
runtime detection of availability of lock-free operations, it isn't 
clear what behavior should inter-process atomics have if the required 
operations turn out to be unavailable in run time. This is not a problem 
in the current implementation, as it always uses compile-time detection, 
but I wouldn't want to prohibit runtime detection in the future.