What classification should shared objects in qeued thread pools have?

[IGotD-]

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?