Sharing in D

[superdan]

Steven Schveighoffer Wrote:

> "Walter Bright" wrote
> > Steven Schveighoffer wrote:
> >> "Walter Bright" wrote
> >>> http://www.reddit.com/comments/6u7k0/sharing_in_d/
> >>
> >> There are 2 problems I see with this scheme.
> >>
> >> First, that the default is 'unshared'.  This is going to break a lot of 
> >> existing code, and make peoples lives miserable who do not want to deal 
> >> with unshared non-stack data.
> >
> > 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'
> 
> >> I would hazard to guess that adopting this would cause a larger rift than 
> >> const.
> >
> > Perhaps. But the alternative is the current wild west approach to 
> > multithreaded programming. With the proliferation of multicore computers, 
> > the era where this is acceptable is coming to an end.
> 
> 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)?  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.  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.
> 
> I may be wrong, and this shared/unshared thing will be really great for 
> people.  But I think it needs a lot of work before it's helpful.  In its 
> current incarnation, I'll call it the 'shared wild west' approach :P
> 
> >> Second, the fact that you can't implicitly cast shared to unshared and 
> >> vice versa.  It's going to make communication between both 'worlds' very 
> >> error prone, as you will be required to cast for any call from one to the 
> >> other.
> >
> > I think the reverse is true. Moving data between those worlds is dangerous 
> > and needs to be carefully vetted, so requiring an explicit cast will 
> > reduce the chance of this happening unintentionally.
> 
> 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 :)
> 
> >> People will do this just to get their code to work, without thinking 
> >> about the consequences.
> >
> > 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.
> 
> >
> >> Even those that do think about the consequences, can't have the compiler 
> >> statically check the cast in either direction, so once you cast, you lose 
> >> all the benefit.
> >
> > But still, you're far better off than the current wild west approach where 
> > everything is implicitly shared with no protection whatsoever. The popular 
> > double checked locking bug will be impossible to code in D without 
> > stuffing in explicit casts. The casts will be a red flag that the 
> > programmer is making a mistake.
> >
> 
> Please let me decide whether I'm far better off.  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 :)
> 
> -Steve 

you may as well be equally right. or even more right, as you usually are. sure you are a great hacker who knows threads in and out, as "you spend a lot of time thinking about multithreaded issues". i'm impressed. i do suggest you run a lil experiment one day tho. google for walter bright. figure out what kinds of shit he's done. google for bartosz milewski. figure out for what kinds of shit he's done. google for andrei alexanderescu. figure out for what kinds of shit he's done. then google for steven schveighoffer. unless sure enough you are hans boehm in disguise. then ask yourself. "is my big mouth going to make up for all this?"