What classification should shared objects in qeued thread pools have?
nise at nise.com
Thu Oct 1 14:25:07 UTC 2020
On Thursday, 1 October 2020 at 14:12:24 UTC, Ola Fosheim Grøstad
> 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?
More information about the Digitalmars-d-learn