On Thursday, 1 October 2020 at 14:12:24 UTC, Ola Fosheim Grøstad
wrote:
Also, atomic operations on members do not ensure the integrity
of the struct. For that you need something more powerful
(complicated static analysis or transactional memory).
I'm very wary of being able to cast away shared, it might
completely negate all the advertised (memory management)
optimization opportunities for shared.
For that to work you need some kind of "unshared" or "borrowed"
like concept.
Making all variables atomic in a shared struct is a intelligent
as putting all hands on 4:00 on an analogue alarm clock if you
want to wake up at 4:00.
Atomic operations in itself does not ensure thread safety, you
can still have races and the lockless algorithm might not be
waterproof. They can be very difficult to design. Sometimes, this
can show up months after a product has gone live.
Furthermore, there is also the possibility to use locking
primitives (mutexes, read write locks) inside a shared struct to
ensure the thread safety. In that case you really don't all the
data member operations to be atomic.
In order to have "everything allowed" struct like in C++,
shouldn't __gshared also work so that the allocator can
successfully do its operations from several threads?
