Sharing in D

[Steven Schveighoffer]

"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