valid uses of shared

[Artur Skawina]

On 06/11/12 14:11, Steven Schveighoffer wrote:
> On Mon, 11 Jun 2012 07:56:12 -0400, Artur Skawina <art.08.09 at gmail.com> wrote:
> 
>> On 06/11/12 12:35, Steven Schveighoffer wrote:
> 
>>> I wholly disagree.  In fact, keeping the full qualifier intact *enforces* incorrect code, because you are forcing shared semantics on literally unshared data.
>>>
>>> Never would this start ignoring shared on data that is truly shared.  This is why I don't really get your argument.
>>>
>>> If you could perhaps explain with an example, it might be helpful.
>>
>> *The programmer* can then treat shared data just like unshared. Because every
>> load and every store will "magically" work. I'm afraid that after more than
>> two or three people touch the code, the chances of it being correct would be
>> less than 50%...
>> The fact that you can not (or shouldn't be able to) mix shared and unshared
>> freely is one of the main advantages of shared-annotation.
> 
> If shared variables aren't doing the right thing with loads and stores, then we should fix that.

Where do you draw the line?

shared struct S {
   int i
   void* p;
   SomeStruct s;
   ubyte[256] a;
}

shared(S)* p = ... ;

auto v1 = p.i;
auto v2 = p.p;
auto v3 = p.s;
auto v4 = p.a;
auto v5 = p.i++;

Are these operations on shared data all safe? Note that if these
accesses would be protected by some lock, then the 'shared' qualifier
wouldn't really be needed - compiler barriers, that make sure it all
happens while this thread holds the lock, would be enough. (even the
order of operations doesn't usually matter in that case and enforcing
one would in fact add overhead)



> But leaving things "the way they are" doesn't fix any problems:
> 
> shared int x;
> 
> void main()
> {
>     auto y = x; // typeof(y) == shared(int)
>     y += 5;
>     x = y;
> }
> 
> How is this any more "correct" than if y is int?

Not allowing the implicit conversions does not fix all cases, yes.
It will catch /some/ invalid uses. It's a step towards a saner model.
Where "raw" access like in your example won't be allowed.
Yes, it would need a compiler flag.

When I say that I think your ideas are a step in the right direction,
it's because I know where the journey will eventually lead us... :)
I'm not sure forbidding direct manipulation is the ultimate goal, but
it is a safe base for the next stage, which would be figuring out
which cases can be allowed, because the compiler will always be able
to do the right thing. Starting out by allowing everything is what got
us into this mess in the first place.

artur