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

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
On Sun, 31 May 2020 at 16:05, Andrey Semashev via Boost <
[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
On 2020-06-01 13:50, degski wrote:

>
> On Sun, 31 May 2020 at 16:05, Andrey Semashev via Boost
> <[hidden email] <mailto:[hidden email]>> 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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.





_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Mon, 1 Jun 2020 at 06:18, Andrey Semashev via Boost <
[hidden email]> wrote:

> On 2020-06-01 13:50, degski wrote:
> >
> > On Sun, 31 May 2020 at 16:05, Andrey Semashev via Boost
> > <[hidden email] <mailto:[hidden email]>> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 2020-06-01 15:07, degski wrote:

>
> On Mon, 1 Jun 2020 at 06:18, Andrey Semashev via Boost
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     On 2020-06-01 13:50, degski wrote:
>      >
>      > On Sun, 31 May 2020 at 16:05, Andrey Semashev via Boost
>      > <[hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>> 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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list

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




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

smime.p7s (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list


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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

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

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list


> On 2. Jun 2020, at 17:37, Andrey Semashev via Boost <[hidden email]> wrote:
>
> On 2020-06-02 17:28, Hans Dembinski via Boost wrote:
>>> On 2. Jun 2020, at 11:21, Alexander Grund via Boost <[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

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

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost