shared - i need it to be useful
Steven Schveighoffer
schveiguy at gmail.com
Tue Oct 16 18:29:42 UTC 2018
On 10/16/18 2:10 PM, Manu wrote:
> On Tue, Oct 16, 2018 at 6:35 AM Steven Schveighoffer via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>>
>> On 10/16/18 9:25 AM, Steven Schveighoffer wrote:
>>> On 10/15/18 2:46 PM, Manu wrote:
>>
>>>>> From there, it opens up another critical opportunity; T* -> shared(T)*
>>>> promotion.
>>>> Const would be useless without T* -> const(T)* promotion. Shared
>>>> suffers a similar problem.
>>>> If you write a lock-free queue for instance, and all the methods are
>>>> `shared` (ie, threadsafe), then under the current rules, you can't
>>>> interact with the object when it's not shared, and that's fairly
>>>> useless.
>>>>
>>
>> Oh, I didn't see this part. Completely agree with Timon on this, no
>> implicit conversions should be allowed.
>
> Why?
int x;
shared int *p = &x; // allow implicit conversion, currently error
passToOtherThread(p);
useHeavily(&x);
How is this safe? Thread1 is using x without locking, while the other
thread has to lock. In order for synchronization to work, both sides
have to agree on a synchronization technique and abide by it.
>> If you want to have a lock-free implementation of something, you can
>> abstract the assignments and reads behind the proper mechanisms anyway,
>> and still avoid locking (casting is not locking).
>
> Sorry, I don't understand what you're saying. Can you clarify?
>
I'd still mark a lock-free implementation shared, and all its methods
shared. shared does not mean you have to lock, just cast away shared. A
lock-free container still has to do some special things to make sure it
avoids races, and having an "unusable" state aids in enforcing this.
-Steve
More information about the Digitalmars-d
mailing list