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