shared - i need it to be useful

[Nicholas Wilson]

On Sunday, 21 October 2018 at 22:12:18 UTC, Neia Neutuladh wrote:
> On Sun, 21 Oct 2018 12:04:16 -0700, Manu wrote:
>> On Sun, Oct 21, 2018 at 12:00 PM Timon Gehr via Digitalmars-d 
>> <digitalmars-d at puremagic.com> wrote:
>>> Note that there may well be a good way to get the good 
>>> properties of MP without breaking the type system, but MP 
>>> itself is not good because it breaks @safe.
>> 
>> Show me. Nobody has been able to show that yet. I'd really 
>> like to know this.
>
> If we only used your proposal and only used @safe code, we 
> wouldn't have any data races,

Only of the @trusted implementation is thread safe, which it 
_should_ be. This is the same caveat as non threaded 
- at safe/@tusted code.

> but that's only because we wouldn't have any shared data. We'd 
> have shared *variables*, but they would not contain any data we 
> could read

Reads must be atomic.

> or alter, and that's pretty much useless.
>
> To use your proposal, we need to cast data back from shared to 
> unshared.

Yes but this is in the @trusted implementation that forms the 
basis of your threadsafety.

> When it's unshared, we need to make sure that exactly one 
> thread has a reference to that data as unshared.

Nod.

>And @safe *should* help us with that.

Nod.

> Currently, it helps because casting unshared to shared is not 
> @safe,

This remains the case, and should be done (enforced by the 
compiler) only in @trusted/@system code as a basis for thread 
safe, @safe code.

> because it makes it trivial to get multiple threads with 
> unshared references to the same data.

That is @trusted or @system code and therefore is the programmers 
responsibility.

> And that's when you're using shared as expected rather than 
> doing something weird.

That forms the basis of your thread safe stack. From there on, 
the basis that shared arguments to functions are treated safely 
in the presence of threading means that code that calls the 
@trusted implementations is @safe.