Sharing in D

[downs]

Walter Bright wrote:
> downs wrote:
>> Walter Bright wrote:
>>> Steven Schveighoffer wrote:
>>>> I would hazard to guess that adopting this would cause a larger
>>>> rift than const.
>> He's probably right.
> 
> A couple years ago, I was in a room with 30 of the top C++ programmers
> in the country. The topic was a 2 day conference on how to support
> multithreading in C++. It soon became clear that only two people in the
> room understood the issues (and I wasn't one of them).
> 
> I think I understand the issues now, but it has taken a long time and
> repeatedly reading the papers about it. It is not simple, and it's about
> as intuitive as quantum mechanics.
> 
> I suggested to Andrei and Bartosz just the other day that I don't expect
> the value in this model will be readily apparent. I'm pretty sure it
> won't be, as the issues are hard to understand. But the issues being
> hard to understand is exactly why this model is needed. There are surely
> several articles, papers, and tutorials in this :-)
> 
> 
>>> 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.
>>
>> Since when is it the language's job to tell us what's acceptable and
>> what's not?
> 
> I meant that programmers will no longer find the language acceptable if
> it doesn't offer better support.
> 
> 
>>> 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.
>>
>> The double checked locking "bug" is only a bug on certain
>> architectures, none of which D is supported on.
> 
> D is not only meant to be more than an x86 only language, the x86 family
> steadily moves towards the relaxed sequential consistency model. The
> threading model supported by Java and the upcoming C++0x release are
> both based on the relaxed model, that is clearly where the industry
> expects things to go, and I see no reason to believe otherwise.

Point taken, taken and taken.

If this can be done well, I believe it may become a significant advantage for the language.

IMHO, however, most global variables are intended to be instantiated only once, not once per thread. Because of this, the success of this model hinges on how easy an object can be transferred between threads. Some sort of language enforced blocking, maybe?

I.e. if you mark an object as unique, as in, "unique Class foo", it is implicitly shared, but *treated as if it were nonshared*, as threads need to acquire a sync lock before accessing the object, and references to the object or its members cannot leave the sync block.

Delegates would be a special case: they can leave the sync lock, as long as any "this" access inside them is itself synchronized.

 --downs