shared - i need it to be useful

[Manu]

On Tue, Oct 16, 2018 at 6:25 AM Timon Gehr via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
>
> On 16.10.2018 13:04, Dominikus Dittes Scherkl wrote:
> > On Tuesday, 16 October 2018 at 10:15:51 UTC, Timon Gehr wrote:
> >> On 15.10.2018 20:46, Manu wrote:
> >>>
> >>> Assuming the rules above: "can't read or write to members", and the
> >>> understanding that `shared` methods are expected to have threadsafe
> >>> implementations (because that's the whole point), what are the risks
> >>> from allowing T* -> shared(T)* conversion?
> >>>
> >>
> >> Unshared becomes useless, and in turn, shared becomes useless.
> > why is unshared useless?
> > Unshared means you can read an write to it.
> > If you give it to a function that expect something shared,
> > the function you had given it to can't read or write it, so it
> > can't do any harm.
>
> It can do harm to others who hold an unshared alias to the same data and
> are operating on it concurrently.

Nobody else holds an unshared alias.
If you pass a value as const, you don't fear that it will become mutable.

> > Of course it can handle it threadsave, but as it is local,
> > that is only overhead - reading or changing the value can't do
> > any harm either. I like the idea.
> >
> >> But useless, because there is no way to ensure thread safety of reads
> >> and writes if only one party to the shared state knows about the sharing.
> > Of course there is.
>
> Please do enlighten me. You have two processors operating
> (reading/writing) on the same address space on a modern computer
> architecture with a weak memory model, and you are using an optimizing
> compiler. How do you ensure sensible results without cooperation from
> both of them? (Hint: you don't.)

What? This is a weird statement.
So, you're saying that nobody has successfully written any threadsafe
code, ever... we should stop trying, and we should admit that
threadsafe queues and atomics, and mutexes and stuff all don't exist?

> without cooperation from both of them?

Perhaps this is the key to your statement?
Yes. 'cooperation from both of them' in this case means, they are both
interacting with a threadsafe api, and they are blocked from accessing
members, or any non-threadsafe api.

> > Giving an unshared value to a function that
> > even can handle shared values may create some overhead, but is
> > indeed threadsave.
> >
>
> Yes, if you give it to one function only, that is the case. However, as
> you may know, concurrency means that there may be multiple functions
> operating on the data _at the same time_. If one of them operates on the
> data as if it was not shared, you will run into trouble.

Who's doing this, and how?

> You are arguing as if there was either no concurrency or no mutable
> aliasing.

If a class has no shared methods, there's no possibility for mutable aliasing.
If the class has shared methods, then the class was carefully designed
to be threadsafe.