Sharing in D

[Walter Bright]

Steven Schveighoffer wrote:
> "Walter Bright" wrote
>> Nearly all global data is assumed to be and treated as if it were 
>> unshared. So making unshared the default is the right solution. And 
>> frankly, if you're using a lot of global variables, you might want to 
>> reevaluate what you're doing. Lots of global variables is the 80's style 
>> of programming :-)
> I have no idea where you came up with this.  To me global means shared. 
> Global means the world can see it, meaning that it's shared between all. 
> Even VB.net uses 'Shared' as the keyword to mean 'global'

The idea is that encapsulation is better, and having something shared 
between everyone violates encapsulation. When you have a global variable 
'int x' that everyone can read and write to, and there's a bug, you have 
the whole program to search for that bug. The principle of encapsulation 
is that each chunk of data is visible only to the code that needs to see 
it, and no more.

(Programming languages started out with everything being global data, 
and has moved away from that ever since.)


> Yeah, because all us cowboys don't like your kind.  Maybe we need to get us 
> a rope and have a lynchin.  Seriously, how can you say that the current 
> threadding tools are 'uncontrolled' (i.e. wild west)?

Because of the common multithreaded bug 
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
for one example. There is no threading tool I'm aware of that can 
prevent or detect such bugs.


> I spend lots of time 
> thinking about multithreadded issues, and make sure my software works 
> properly.  I think the level of quality for threadding issues depends on the 
> coder, not the tools.

I believe the tools can make it easier.

> In the case of shared/unshared, it's not going to 
> change anything, except now I have to declare things I didn't have to 
> declare before.  I.e. having shared/unshared is going to be just as wild as 
> before.

Why? First of all, unshared data isn't going to have sequential or sync 
issues, by definition. Already, you've cut the problem domain down by a 
huge chunk. Next, shared data access will come with fences or sync. That 
isn't going to guarantee no deadlocks, but it will guarantee sequential 
consistency, and at the very least will dramatically cut the problem 
domain down.


> Except now instead of the compiler helping you, you have pushed aside that 
> help and said 'I know what I'm doing'.  Oops, back to the wild west :)

If you want the wild west, you have it, if you want compiler help 
instead, you got it. How is that worse than C++ or Java, where you 
always have the wild west and no help at all?


>> True, but having it happen implicitly is even worse, because there's no 
>> indication that it is happening.
> 
> dmd mycode.d
> Error: when calling foo(shared int *), cannot pass int *
> 
> edit mycode.d, cast to shared int *
> 
> OK, now it works :)  Probably without any problems, because the compiler has 
> no idea whether I'm going to change it in another thread.  Hell, I might not 
> even HAVE more than one thread!
> 
> But the result is, we're back to the same model as before.  And now I have 
> to cast everything.   Annoying.

Non-shared can be implicitly cast to shared, as that is always safe. 
Just not the other way.


> Please let me decide whether I'm far better off.

Ok. D offers both - and for the guy maintaining your code, there'll at 
least be clear indications of where to look for the source of elusive 
threading bugs.

Optlink currently has a threading bug in it. I have no idea where to 
look for it in the source code.

> I don't need protection 
> from stuff that doesn't matter.  I will still have to lock shared data, and 
> still have to cast to get things to work, so I'm not better off.  You can't 
> tell me otherwise, because all this stuff is a figment of your imagination. 
> You have no proof.  Until you can show me that I'm better off with an actual 
> example, then I believe we both are equally right :)

I didn't think I'd convince anyone the first time around. But I'm 
patient <g>.