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

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2020-06-01 14:24:24

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