DIP 1024--Shared Atomics--Community Review Round 1

[IGotD-]

On Saturday, 12 October 2019 at 21:28:36 UTC, Jonathan M Davis 
wrote:
>
> Right now, we basically have #2. What this DIP is trying to do 
> is move us to #1. How libraries should work is exactly the same 
> in either case. It's just that with #1, the places where you 
> operate on shared data in a manner which isn't guaranteed to be 
> atomic, the compiler prevents you from doing it unless you  use 
> core.atomic or have @system code with casts. Even if we have #2 
> and thus no such compiler errors, the code should still have 
> been doing what #1 would have required, since if it doesn't, 
> then it isn't thread-safe.

With this DIP, shared integers/small types will be automatically 
atomic. For complex/large types, will you still be able to use 
them as before between threads and you have protect the type 
yourself at least for a transitional period?

"Atomic" here as I get it also mean atomically updating complex 
types. This usually means that you need to guard the operations 
with some kind of mutex. The compiler can of course detect this 
and issue a warning/error to the user which doesn't seem to be 
the scope of this DIP.

Correct me if I'm wrong but we have the following scenarios.
1. shared integer/simple type (size dependent?) -> automatically 
HW atomic operations
2. shared complex type -> write to any member must be protected 
with a mutex.
3. shared complex type -> read to any member must be protected 
with a mutex or read/write mutex allowing multiple reads.

The compiler is used the detect these scenarios so that the user 
doesn't forget protecting the shared types.

As I get it this DIP is just a baby step towards this bigger 
scope for the shared keyword.