Sharing in D

[JAnderson]

Steven Schveighoffer wrote:
> "superdan" 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.
>> but the code there *is* different. there are fence combinations & shit. i 
>> guess in such cases you'd need a template.
> 
> The issue I see is that it's not as simple as flipping a switch.  If I want 
> to use an object as a shared object, it needs to implement that shared 
> interface now.  Might as well code a completely different object.  And in 
> that case, can't this just be a library solution (i.e. derive from this 
> object if you want shared access)?  You'd probably need to bring volatile 
> back :)
> 
>>> I think at the very least, for this to be palatable, there needs to be
>>> another modifier that unifies shared and unshared.  Similar to how const
>>> unifies mutable and invariant.
>> sounds interesting but i don't get it. we have:
>>
>> invariant == never changes
>> const == i won't change it
>> mutable == fuck you, i'm changing
>>
>> in the shared cases we have:
>>
>> unshared == never seen by 2 threads
>> ? == ?
>> shared == fuck you, i'm shared
>>
>> so how would that go. i won't share it? i won't write to it? (that's 
>> useless bc of read fences.) anyway this is intriguing shit. unification is 
>> power.
> 
> I have no idea what the middle ground is :)  I'm just saying that without 
> that middle ground, it's going to feel like I'm writing code specifically 
> for sharing or not sharing, and the shared keyword loses a lot of its 
> meaning as a general type modifier.  I can't just slap a shared label on 
> anything because that object needs to be specifically written to be a shared 
> object.
> 
> And in the case of functions which take those objects or data types as 
> parameters, slapping a shared label on something means I have to use a 
> completely different set of functions, which might not exist.  If I have to 
> use a library for some reason or another, I might just be tempted to cast 
> away the shared.  I might have no other choice.
> 
> -Steve 
> 

Hopefully the shared data will be encapsulated such that you communicate 
with it though some lightweight class that converts the pieces that your 
sharing into something unshared functions can work with.  We might then 
only need a small set of standard lib functions for shared memory which 
do mostly shared memory specific stuff.  However we'll see how things go 
I guess.

-Joel