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

Andrey Semashev

31 May 2020 31 May '20

9:05 p.m.

Hi, As some of you may know, C++20 added new waiting/notifying operations to std::atomic: wait, notify_one and notify_all. These operations are not address-free, i.e. their implementation is allowed to use process-local addresses of the atomics as keys. In particular, it means you can't use them for inter-process communication. In Boost.Atomic I intend to provide address-free variants as well, where possible, and I'm thinking about the naming scheme for them. Currently, I'm using the "_address_free" suffix, so we have wait_address_free, notify_one_address_free and notify_all_address_free. The "address-free" term comes from the C++ standard, but the resulting names seem a bit long. Maybe there are better suggestions? Thanks.

Show replies by date

degski

1 Jun 1 Jun

10:50 a.m.

On Sun, 31 May 2020 at 16:05, Andrey Semashev via Boost < boost@lists.boost.org> wrote:

...

The "address-free" term comes from the C++ standard, but the resulting names seem a bit long. Maybe there are better suggestions?

What about "global_"-prefix or "_system"-post-fix ("_sys")? degski -- @systemdeg https://www.instapaper.com http://instapaper.com "We value your privacy, click here!" Sod off! - degski

Andrey Semashev

11:17 a.m.

On 2020-06-01 13:50, degski wrote:

...

On Sun, 31 May 2020 at 16:05, Andrey Semashev via Boost mailto:boost@lists.boost.org> wrote:

The "address-free" term comes from the C++ standard, but the resulting names seem a bit long. Maybe there are better suggestions?

What about "global_"-prefix or "_system"-post-fix ("_sys")?

Hmm, that doesn't quite communicate the difference from the default operations.

degski

12:07 p.m.

On Mon, 1 Jun 2020 at 06:18, Andrey Semashev via Boost < boost@lists.boost.org> wrote:

...

On 2020-06-01 13:50, degski wrote:

...
On Sun, 31 May 2020 at 16:05, Andrey Semashev via Boost mailto:boost@lists.boost.org> wrote:

The "address-free" term comes from the C++ standard, but the resulting names seem a bit long. Maybe there are better suggestions?

What about "global_"-prefix or "_system"-post-fix ("_sys")?

Hmm, that doesn't quite communicate the difference from the default operations.

On the assumption that the std-post-fixes have already extensively been bike-shedded, any alternative will likely be a compromise between length and descriptiveness, so your 'hmmm ...' is natural, I'm thinking about words around 'virtual memory' (because that's where the non-local addresses come from), while "_virtual" is out of the question. degski -- @systemdeg https://www.instapaper.com http://instapaper.com "We value your privacy, click here!" Sod off! - degski

Andrey Semashev

2:24 p.m.

On 2020-06-01 15:07, degski wrote:

...

On Mon, 1 Jun 2020 at 06:18, Andrey Semashev via Boost mailto:boost@lists.boost.org> wrote:

On 2020-06-01 13:50, degski wrote: > > On Sun, 31 May 2020 at 16:05, Andrey Semashev via Boost > mailto:boost@lists.boost.org mailto:boost@lists.boost.org>> wrote: > > The "address-free" > term comes from the C++ standard, but the resulting names seem a bit > long. Maybe there are better suggestions? > > > What about "global_"-prefix or "_system"-post-fix ("_sys")?

Hmm, that doesn't quite communicate the difference from the default operations.

On the assumption that the std-post-fixes have already extensively been bike-shedded, any alternative will likely be a compromise between length and descriptiveness, so your 'hmmm ...' is natural, I'm thinking about words around 'virtual memory' (because that's where the non-local addresses come from), while "_virtual" is out of the question.

Many platforms use the term "physical address" to describe the underlying key source. However, wait_physical_address is not really better than wait_address_free. I've also considered "_pshared" suffix, which comes from POSIX, but the address-free operations can also be useful within the same process, when the atomic object is mapped at multiple addresses.

Phil Endecott

12:05 p.m.

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

Andrey Semashev wrote:

...

As some of you may know, C++20 added new waiting/notifying operations to std::atomic: wait, notify_one and notify_all. These operations are not address-free, i.e. their implementation is allowed to use process-local addresses of the atomics as keys. In particular, it means you can't use them for inter-process communication.

That's useful to know!

...

In Boost.Atomic I intend to provide address-free variants as well, where possible, and I'm thinking about the naming scheme for them. Currently, I'm using the "_address_free" suffix, so we have wait_address_free, notify_one_address_free and notify_all_address_free. The "address-free" term comes from the C++ standard, but the resulting names seem a bit long. Maybe there are better suggestions?

boost::interprocess::atomic. P.S. it's not "bikeshedding", names are important. Regards, Phil.

Andrey Semashev

2:17 p.m.

On 2020-06-01 15:05, Phil Endecott via Boost wrote:

...

...
In Boost.Atomic I intend to provide address-free variants as well, where possible, and I'm thinking about the naming scheme for them. Currently, I'm using the "_address_free" suffix, so we have wait_address_free, notify_one_address_free and notify_all_address_free. The "address-free" term comes from the C++ standard, but the resulting names seem a bit long. Maybe there are better suggestions?

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.

Alexander Grund

2 Jun 2 Jun

9:21 a.m.

...

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

Hans Dembinski

2:28 p.m.

...

On 2. Jun 2020, at 11:21, Alexander Grund via Boost 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 :)

...

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

Andrey Semashev

3:37 p.m.

On 2020-06-02 17:28, Hans Dembinski via Boost wrote:

...

...
On 2. Jun 2020, at 11:21, Alexander Grund via Boost 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.

Hans Dembinski

3 Jun 3 Jun

12:44 p.m.

...

On 2. Jun 2020, at 17:37, Andrey Semashev via Boost wrote:

On 2020-06-02 17:28, Hans Dembinski via Boost wrote:

...
...
On 2. Jun 2020, at 11:21, Alexander Grund via Boost 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?).

Makes sense. I guess we all agree that redundancy in names/namespaces is bad. If the hypothetical namespace boost::atomics::interprocess is going to contains only a single type anyway, then boost::atomics::interprocess_atomic<int> seems like a good compromise to me, or maybe boost::atomics::ipc_atomic<int> if you want it shorter. Best regards, Hans

Bjorn Reese

7 Jun 7 Jun

1:35 p.m.

On 2020-06-03 14:44, Hans Dembinski via Boost wrote:

...

Makes sense. I guess we all agree that redundancy in names/namespaces is bad. If the hypothetical namespace boost::atomics::interprocess is going to contains only a single type anyway, then boost::atomics::interprocess_atomic<int> seems like a good compromise to me, or maybe boost::atomics::ipc_atomic<int> if you want it shorter.

Or inter_atomic<T> if we want something that is easily pronounced.

1633

Age (days ago)

1640

Last active (days ago)

List overview

Download

11 comments

6 participants

participants (6)

Alexander Grund
Andrey Semashev
Bjorn Reese
degski
Hans Dembinski
Phil Endecott