On Wednesday, 2 June 2021 at 14:50:44 UTC, rm wrote:
> *snip*

Sorry, but I don't feel like anything you wrote relates to anything I actually said.  For example:

> Anyway, I disagree about the simple cases. Because specifically the case of simple event counter that isn't require for synchronization, you should be using relaxed. There is no need for sequential consistency in this case.

The "simple cases" comment was about how the "thread-safe value" abstraction only works at all in a few simple cases (such as an event counter that doesn't affect flow of control).  No one has implied anything about what memory order you need for a counter.

But if you do consider memory order, that's more reason to treat atomic operations as explicit atomic *operations*, and not wrap them in a "thread-safe value" abstraction.

On 03/06/2021 1:04, sarn wrote:
> On Wednesday, 2 June 2021 at 14:50:44 UTC, rm wrote:
>> *snip*
> 
> Sorry, but I don't feel like anything you wrote relates to anything I actually said.  For example:
> 
>> Anyway, I disagree about the simple cases. Because specifically the case of simple event counter that isn't require for synchronization, you should be using relaxed. There is no need for sequential consistency in this case.
> 
> The "simple cases" comment was about how the "thread-safe value" abstraction only works at all in a few simple cases (such as an event counter that doesn't affect flow of control).  No one has implied anything about what memory order you need for a counter.
> 
> But if you do consider memory order, that's more reason to treat atomic operations as explicit atomic *operations*, and not wrap them in a "thread-safe value" abstraction.

I think I was conflating two replies into one and misread your response.

Either way, it does allow for easier porting from C/C++ if such code is used.