DIP 1024--Shared Atomics--Community Review Round 1
nise at nise.com
Sat Oct 12 23:37:50 UTC 2019
On Saturday, 12 October 2019 at 21:28:36 UTC, Jonathan M Davis
> 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.
More information about the Digitalmars-d