shared - i need it to be useful

Timon Gehr timon.gehr at gmx.ch
Wed Oct 17 12:15:58 UTC 2018


On 16.10.2018 19:25, Manu wrote:
> On Tue, Oct 16, 2018 at 3:20 AM Timon Gehr via Digitalmars-d
> <digitalmars-d at 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.


More information about the Digitalmars-d mailing list