Fixing core.atomic (page 2)

On Monday, 31 May 2021 at 08:52:33 UTC, IGotD- wrote: > > However, the assignment operator writing s = 1 is nice instead of s.store(1). I don't think so, it's a bit implicit meaning to be atomic, so it falls under "nice short syntax for something pretty much important": a terrible idea.

On Monday, 31 May 2021 at 09:26:36 UTC, rm wrote: > > I don't consider this a problem. In this case you have a load and a store. This is a non-atomic RMW. On the other hand, you do get sequential consistency synchronization from this process. I prefer atomicLoad and atomicStore then, because it's explicit and it's useless to hide the fact it's atomic behind nice syntax.

On Monday, 31 May 2021 at 16:34:35 UTC, Guillaume Piolat wrote: > > I prefer atomicLoad and atomicStore then, because it's explicit and it's useless to hide the fact it's atomic behind nice syntax. Yes, you can use it if you want to. We will not remove the regular D atomic functions.

On Monday, 31 May 2021 at 16:34:35 UTC, Guillaume Piolat wrote: > On Monday, 31 May 2021 at 09:26:36 UTC, rm wrote: >> >> I don't consider this a problem. In this case you have a load and a store. This is a non-atomic RMW. On the other hand, you do get sequential consistency synchronization from this process. > > I prefer atomicLoad and atomicStore then, because it's explicit and it's useless to hide the fact it's atomic behind nice syntax. Yes, how often do people use this anyway? I try to avoid concurrency issues and have found that I tend to end up using compare-exchange when I have to.

May 31, 2021

Re: Fixing core.atomic

Posted by Ola Fosheim Grøstad
in reply to Max Haughton

Permalink

Ola Fosheim Grøstad

Posted in reply to Max Haughton

Permalink

On Monday, 31 May 2021 at 20:01:57 UTC, Max Haughton wrote:

On Monday, 31 May 2021 at 17:51:26 UTC, IGotD- wrote:

On Monday, 31 May 2021 at 16:34:35 UTC, Guillaume Piolat wrote:

I prefer atomicLoad and atomicStore then, because it's explicit and it's useless to hide the fact it's atomic behind nice syntax.

Yes, you can use it if you want to. We will not remove the regular D atomic functions.

That and the C++ std::atomic will provide the same semantics on types of wide size (LDC and GDC seem to differ in behaviour here when you use the atomic primitive functions.)

Are you sure?

«All atomic types except for std::atomic_flag may be implemented using mutexes or other locking operations, rather than using the lock-free atomic CPU instructions.»

https://en.cppreference.com/w/cpp/atomic/atomic_is_lock_free

C/C++ is trying to be hardware-independent to a much larger extent than D.

On Monday, 31 May 2021 at 20:43:37 UTC, Ola Fosheim Grøstad wrote:

On Monday, 31 May 2021 at 20:01:57 UTC, Max Haughton wrote:

On Monday, 31 May 2021 at 17:51:26 UTC, IGotD- wrote:

[...]

That and the C++ std::atomic will provide the same semantics on types of wide size (LDC and GDC seem to differ in behaviour here when you use the atomic primitive functions.)

Are you sure?

«All atomic types except for std::atomic_flag may be implemented using mutexes or other locking operations, rather than using the lock-free atomic CPU instructions.»

https://en.cppreference.com/w/cpp/atomic/atomic_is_lock_free

C/C++ is trying to be hardware-independent to a much larger extent than D.

"Atomic types are also allowed to be sometimes lock-free"

https://gcc.godbolt.org/z/Ph981GvY8 Note the use of library calls.

Forums