shared - i need it to be useful

[Neia Neutuladh]

On Sun, 21 Oct 2018 17:35:38 -0700, Manu wrote:

> On Sun, Oct 21, 2018 at 3:15 PM Neia Neutuladh via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>> If we only used your proposal and only used @safe code, we wouldn't
>> have any data races, 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 or alter, and that's pretty much useless.
> 
> I've shown an implementation of Atomic(T) 3 times now... no response any
> time. Why is it being dismissed? Do I need to write it more times?
> This is a clear demonstration of how to build the foundation of the
> @safe threadsafe stack.

Yes, Atomic can be implemented here as @trusted code, and maybe using 
@safe compiler intrinsics for some situations. That's useful! But it's not 
*enough*.

It would require a lot of work to refit existing code to using only atomic 
operations, and it would end up looking rather clunky a lot of the time. 
If you're doing anything complex with a complex object graph, you're going 
to have a terrible time. You need to copy that object graph (atomically), 
which is going to be expensive and provides non-trivial restrictions on 
what you can store.

So I'm not keen on a world in which all multithreading is using atomic 
structs.

Unless, when you were talking about Atomic, you actually meant a wrapper 
containing some sort of lock, allowing you to submit arbitrary delegates 
to mutate the data within in a serialized way, similar to Atila Neves's 
fearless library. Which really stretches the definition of "atomic".

>> Currently, it helps because casting unshared to shared is not @safe,
>> because it makes it trivial to get multiple threads with unshared
>> references to the same data.
> 
> No no, that's a massive smell. That means anytime anyone wants to
> distribute something, they need to perform unsafe casts. That's not
> okay.

Casting thread-local to shared makes it easy to cause errors, and that's 
why it's a massive smell. Making it silent doesn't eliminate the smell.

> 100% of my SMP code works with my proposal, and something close to 0%
> works with shared as it is today. (assuming we desire @safe interaction,
> which we do, because threading is hard enough already!)

You want un-shared things to implicitly cast to shared. You don't want to 
have to allocate anything as shared, and you do want to pass absolutely 
anything to any thread.

You can write a @trusted assumeShared function, analogous to assumeUnique, 
to accomplish that. It would be slightly more awkward than what you're 
proposing, but it accomplishes one of your two goals: convert non-shared 
things to shared things in @safe code.

The other goal in your proposal is for some code that currently compiles 
not to. So you should be able to write the code you want, albeit with an 
increased risk of bugs. Or you could write a template that wraps a shared 
thing and forbids field access and assignment.

>> And that's when you're using shared as expected rather than doing
>> something weird.
> 
> No, I *expect* to use shared in @safe code, and not write any unsafe
> code ever. shared doesn't model a useful interaction now, not in any
> way.
> 
> Today, access to shared data members are unrestricted and completely
> unsafe

Yes, and that's bad and should be changed.

> passing data into something like a parallel-for requires unsafe
> casts.

Or allocating data as shared, which is the recommended way, because that 
makes absolutely certain that, from the start, no code has an un-shared 
copy of that data. No casts needed.