Shared

[Dominikus Dittes Scherkl]

On Thursday, 16 May 2019 at 17:29:25 UTC, Jonathan M Davis wrote:
> On Thursday, May 16, 2019 11:11:19 AM MDT Simen Kjærås via 
> Digitalmars-d wrote:
>> On Thursday, 16 May 2019 at 15:47:37 UTC, Dominikus Dittes
>>
>> Scherkl wrote:
>> > On Thursday, 16 May 2019 at 11:15:13 UTC, Jonathan M Davis
>> >
>> > wrote:
>> >> [...] that is assuming that it's not possible to have any 
>> >> other references to the same data, which would be too 
>> >> restrictive to be useful. Having multiple references to the 
>> >> same data is a core concept of sharing data across threads.
>> >
>> > Hm. I don't understand the necessity of this. If I have a
>> > shared symbol x,
>> > this same symbol can be used in different threads, no? I 
>> > can't
>> > see why multiple threads need to have different references to
>> > the same data. They just can use the same reference.
>>
>> Well, no. The reference is the part that gets copied around. 
>> It's the address of the shared object. When you do 'auto ref2 
>> = ref1;', you're creating a new reference to an already 
>> existing object, but leaving the object itself unchanged.
>>
>> If more than one thread can access the same object, that means 
>> they each have a copy of the reference*. In the same way, when 
>> you call a function with a class argument, that function 
>> receives a copy of the reference (but not the object). Clearly 
>> then, the ability to create multiple references to the same 
>> object must be possible without breaking shared.
>
> Exactly. And since everything in D is thread-local by default, 
> it's usually the case that a variable only exists on one 
> thread. shared changes that if the variable is static, but 
> otherwise, you're just passing around a pointer or reference to 
> shared objects within thread-local objects. So, while  you 
> might have a pointer to shared data contained by a variable 
> with the same name on multiple threads, because that variable 
> is thread-local, it's different on different threads. e.g.

Ok, so then a shared object is in fact a specific memory segment. 
So something the GC is already aware of. This makes implementing 
the locking mechanism just more easy. We only need to prevent 
writing to that address, no matter how many references are 
pointing there. And that mechanism is well known in GC's - a 
write barrier. Only new thing is that no other locked block 
pointing in that address area can be executed. I just can't see 
what fundamental, all blocking problem you see with that 
approach. Seems pretty strait forward to me.