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

[Jonathan M Davis]

On Saturday, October 12, 2019 3:15:26 AM MDT Ola Fosheim Grøstad via 
Digitalmars-d wrote:
> On Saturday, 12 October 2019 at 06:31:18 UTC, Jonathan M Davis
>
> wrote:
> > On Friday, October 11, 2019 10:58:29 PM MDT Walter Bright via
> >
> > Digitalmars-d wrote:
> >> On 10/2/2019 3:42 AM, Nicholas Wilson wrote:
> >> > It should be that shared memory access is disabled in all
> >> > contexts,
> >> > which must be worked around with casts,
> >> > which makes the function @system,
> >> > which must then be encapsulated with a @trusted interface in
> >> > order to
> >> > use in @safe code.
> >>
> >> Sounds right.
> >
> > This is pretty much what several of us were arguing for during
> > the discussions about shared at dconf this year.
>
> How are you going to prove that @safe code does not retain
> nonshared-references after the lock has been released?
>
> How does his work with array elements/slices.

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. 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.

- Jonathan M Davis