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