Difference between __gshared and shared.

[Jonathan M Davis via Digitalmars-d]

On Wednesday, 8 July 2015 at 12:51:02 UTC, Dmitry Olshansky wrote:
> On 08-Jul-2015 15:39, wobbles wrote:
>> On Wednesday, 8 July 2015 at 12:21:22 UTC, Jonathan M Davis 
>> wrote:
>>> On Wednesday, 8 July 2015 at 11:02:19 UTC, Márcio Martins 
>>> wrote:
>>>> [...]
>>
>>
>> Interesting, so the main pain of using shared is the 
>> requirement to cast
>> away the shared whenever you want to work on the data in a 
>> synchronized
>> block.
>>
>> Is there any links do you know to the old conversations on what
>> solutions are there for this?
>>
>> My first thought is using the 'with' keyword.
>> shared int mySharedInt;
>> synchronised(mutexObj) with (mySharedInt){
>>      // any references to mySharedInt in this block are 
>> implicitly
>> converted to non-shared
>> }
>
> It's good convention but still convention - who guarantees that 
> the right mutex was locked? The locking protocol is outside of 
> the competence of the compiler.

Yes. That's the problem, and it would be great if we could find a 
solution for it. But as annoying as it is, we're still better off 
than what you get with C++.

> However there are synchronized _class_-es that might play nice 
> with shared b/c very access to them is guarded by built-in 
> mutex.

Yes. If synchronized classes were actually implemented, then that 
provides a compiler guaranteed safe way to strip off the outer 
layered of shared, but it only strips off the outer layer (since 
it can't guarantee that stripping off anymore would be safe), 
which would severely limit its usefulness, and it's rather clunky 
and verbose to have to declare whole classes just to operate on 
shared data. So, thus far, it's the best that we've come up with 
for safely casting away shared in a compiler-guaranteed way, but 
it's still not all that great, and it's not even implemented.

So, ultimately, even if we finally do get synchronized classes, I 
expect that there will be a fair bit of code that's going to have 
to rely on the programmer to correctly and safely cast away 
shared to operate on data, as unappealing as that may be.

Regardless, until we have synchronized classes or another 
solution which does something similar, the idiom that I described 
is pretty much what we have to do, even if it unfortunately 
relies on the programmer following convention and being careful. 
But it is basically what you have to do in languages like C++ 
anyway except that casting is involved, and the portion of the 
code where it's necessary is a lot clearer thanks to the fact 
that shared objects are explicitly shared and how shared doesn't 
allow you to do much.

- Jonathan M Davis