shared - i need it to be useful

[Timon Gehr]

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.

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

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

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