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

[Ola Fosheim Grøstad]

On Saturday, 12 October 2019 at 09:45:41 UTC, Jonathan M Davis 
wrote:
> It's the same as with any @trusted code. It's up to the 
> programmer to ensure that what the code is doing is actually 
> @safe, and if the code isn't able to provide an API that is 
> @safe, then it shouldn't be @trusted.

But didn't Walter in another thread some time ago say that he 
would add Rust-like linear typing for memory management?

If this is the goal, shouldn't you also use linear typing for 
allowing more flexible @safe/@trusted APIs?

> Ultimately, if the programmer casts away shared while a mutex 
> is locked, it's up to the programmer to ensure that no 
> thread-local references to the shared data escape (though scope 
> can help with that) so that when the lock is released, the only 
> references left are shared.

How does that work with arrays. E.g. processing that has 
coroutine/ranges style implementations.  How can you ensure that 
it is impossible for the lock to be released and also making sure 
that all @safe single-threaded array processing code can be used?

You often want to use "shared" for large sections of arrays.

Another thing is that it seems to me that things could go wrong 
if you have slices and dynamic arrays. E.g.:

a. you take a slice of the last element of an unshared dynamic 
array and hand it to one thread.

b. you reduce the length of the dynamic array

c. you hand out an unshared version of the dynamic array to 
another thread which then increase the length of the dynamic 
array in @safe code

Now you have two @safe unshared references to the last element in 
two different threads? I don't have much experience with 
extending dynamic arrays, because I don't like the D semantics of 
it, but isn't this roughly how things could go?