Shared - Another Thread

[Erik van Velzen]

Let me start by saying I'm willing to admit that I was factually 
wrong.

Also keep in mind that "me having an impression" is something 
that is can't be independently verified and you'll have to take 
my at my word. Just that the exact reason for that impression was 
lost to the sands of time.

On Thursday, 18 October 2018 at 20:13:49 UTC, Stanislav Blinov 
wrote:
> On Thursday, 18 October 2018 at 20:10:18 UTC, Erik van Velzen 
> wrote:
>
>> When shared stood up in its current form,  expectation was 
>> made "this will be threadsafe automatically - we'll figure out 
>> how in the future".
>
> It never was like that. At all. I don't think either Walter or 
> Andrei are idiots, do you?
>

Obviously not. But they are not infallible and can also change 
their mind. And features can be used beyond their initially 
envisioned purpose.

>> Because it works for global variables. But it doesn't seem 
>> like an expectation we can deliver on.
>>
>> (I have no direct reference to this but that was certainly my 
>> impression)
>
> Your impression was wrong. Open e.g. TDPL and read up on 
> `shared` how it was envisioned back then.

I don't think the book really supports your argument. The first 
paragraph about shared sound to me like "the compiler will 
automagically fix it".

Only tangentially it is mentioned that you're actually supposed 
to write special code yourself. You would have to be a compiler 
expert to draw the correct conclusion.

Also the last paragraph the quote below is interesting in light 
of our other discussion about casting to shared.

 From  the book:

""""
13.11  The shared Type Qualifier

(...) To the type system, shared indicates that several threads 
have access to a piece of data. The compiler acknowledges that 
reality by restricting operations on shared data and by 
generating special code for the accepted operations.

(...)

Because all shared data is accounted for and protected under the 
aegis of the language, passing shared data via send and receive 
is allowed.

(...)

13.12 Operations with shared Data and Their Effects

Working with shared data is peculiar because multiple threads may 
read and write it at
any moment. Therefore, the compiler makes sure that all 
operations preserve integrity
of data and also causality of operations.
     Reads and writes of shared values are allowed and guaranteed 
to be atomic: nu-
meric types (save for real), pointers, arrays, function pointers, 
delegates, and class ref-
erences. struct types containing exactly one of the mentioned 
types are also readable
and writable atomically. (...)
     For all numeric types and function pointers, shared-qualified 
values are convertible implicitly to and from unqualified values. 
Pointer conversions between shared(T*) and shared(T)* are allowed 
in both directions. Primitives in std.concurrency allow you to
do arithmetic on shared numeric types.
""""