Sharing in D

Steven Schveighoffer schveiguy at yahoo.com
Thu Jul 31 09:07:38 PDT 2008


"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 





More information about the Digitalmars-d mailing list