On 16.10.2018 19:25, Manu wrote:
On Tue, Oct 16, 2018 at 3:20 AM Timon Gehr via Digitalmars-d
<digitalmars-d@puremagic.com> 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. You can't
have unshared/shared aliasing.
What aliasing?
Aliasing means you have two references to the same data. The two
references are then said to alias. An implicit conversion from unshared
to shared by definition introduces aliasing, where one of the two
references is unshared and the other is shared.
Please show a reasonable and likely construction of the
problem. I've been trying to think of it.
...
I have given you an example. I don't care whether it is "reasonable" or
"likely". The point of @safe is to have a subset of the language with a
sound type system.
All the risks that I think have been identified previously assume that
you can arbitrarily modify the data. That's insanity... assume we fix
that... I think the promotion actually becomes safe now...?
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.
What? I don't understand this sentence.
If a shared method is not threadsafe, then it's an implementation
error. A user should expect that a shared method is threadsafe,
otherwise it shouldn't be a shared method! Thread-local (ie, normal)
methods are for not-threadsafe functionality.
Your function can be thread safe all you want. If you have a thread
unsafe function also operating on the same state, you will still get
race conditions. E.g. mutual exclusion is based on cooperation from all
threads. If one of them forgets to lock, it does not matter how
threadsafe all the others are.
