Sharing in D

[Steven Schveighoffer]

"Walter Bright" wrote
> Steven Schveighoffer Wrote:
>> I'm thinking more in the case of functions.  If I have a function foo, 
>> and I
>> want to pass my shared data version to it, I need to re-implement foo 
>> with
>> the parameters as being shared.  Imagine a function with several 
>> parameters,
>> in which you want to pass a combination of shared/unshared.  That's 2^n
>> variations you have to write.
>
> Not necessary, just make them shared. Unshared implicitly converts to 
> shared, so that works. Putting a fence around an unshared read doesn't 
> break anything, etc.

I'm assuming you read my previous example, but I'll rewrite it to 
demonstrate what I'm trying to show:

class sharedObj
{
   private int *_x;
   synchronized shared int x() {return *_x;}
   synchronized shared int x(int y) {*_x = y;}
   synchronized shared void rebind(shared int *y) {_x = y;}
}

shared sharedObj obj;

static this()
{
   obj = new sharedObj;
}

int *x2;

void bar()
{
    obj.x = x2;
    *x2 = 3; // is this supposed to be guaranteed safe?
}

Now, Let's say you have thread 1 which calls bar.  So now thread 1's x2 and 
obj._x point to the exact same data, which is both viewed as shared and 
unshared at the same time.  Is this something that should be allowed?  Would 
you not make the assumption that you can do whatever you want with what x2 
points to without synchronization because it is unshared?  Maybe I don't 
completely understand what you are intending for shared to mean.

I was under the impression that 'unshared' means 'lock free', which cannot 
be enforcable if you can implicitly cast away the 'lock free' aspect of it.

???

-Steve