Sharing in D

Walter Bright newshound1 at digitalmars.com
Thu Jul 31 21:11:52 PDT 2008


Sean Kelly wrote:
>> Java has synchronization and volatile, and it isn't good enough.
> But volatile in Java is completely different.  And Java doesn't support inline
> ASM.  That said, Java post JSR-133 (ie. Java today) is actually fine.  The C++
> 0x people simply didn't copy Java because the Java memory model is too
> strict to appease the performance-crazed folks in the group :-)

 From talking to people who do large scale multithreaded Java programs, 
it is not fine. The problem is that there is no way to look at a 
non-trivial piece of code that you didn't write, and determine if it has 
dependencies on sequential consistency or not.

I'm not arguing that a thread expert cannot make a thread correct 
program in Java and C++. They can. The problem is the inability to 
verify such correctness, no help is available from the language, and the 
dearth of such experts.


> So "shared" will tell the compiler to automatically fence, etc?

Yes.

> Will any actual
> enforcement be done?  And if so, will this be at compile time, run time, or
> both?

Compile time - it's part of the static type checking system.


>> It is avoidable if you're willing to insert a cast. Putting in the cast
>> says "I know how to handle the wild west, let me do it." The cast has
>> zero runtime cost.
> I think that cast is already used far too much as a standard programming
> mechanism in D 2.0.  And I'll admit that I don't entirely understand why
> you don't like const_cast but assertUnique or whatever does exactly that
> behind the scenes.  Should we consider cast to be an evil red flag-throwing
> feature or not?

Cast is the red flag raising feature. The thing about it is that when 
you review code, the cast is where you look for bugs. With Java and C++, 
you have *no clue* where to look for bugs. It reduces the problem domain 
from the entire program to a (hopefully) manageable small subset.



More information about the Digitalmars-d mailing list