Sharing in D

[superdan]

Sean Kelly Wrote:

> == Quote from Walter Bright (newshound1 at digitalmars.com)'s article
> > 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.
> 
> That's the problem with providing such fundamental support for lock-free
> programming: people will try it, and they'll invariably get it wrong.  This
> is actually the reason why I like the minimalist approach of D 1.0 with
> 'volatile'.  Support for lock-free is sufficiently subtle that it's unlikely
> to be used outside of library code.

fraid you might have a slightly specialized definition of what lock-free code is. i think you say that cas-based shit is lock free. but here, this is lock free:

data = 5.4;
dataThere = true;

people use lock-free *everywhere*. just they don't call it that way. they just synchronize through atomic assignments.

i'm not sure at this point how d's shared will improve the above. if i understand that shit correctly you define data and dataThere as shared. then you know assignments occur in the proper sequence (because of the inserted fences and shit). if they weren't shared they could be assigned in the wrong order but nobody could tell. it's like the shit in the forest that don't stink because nobody's smellin'. and if they weren't shared they wouldn't be shareable to start with. so the whole shit works. is that true walt?

> > > 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.
> 
> I've got to admit that I actually like this idea.  It's a breaking change
> that will trigger run-time failures in code when the feature is deployed,
> but in the kind of multithreaded apps I write I'd be labeling perhaps two
> variable declarations in the entire app.

yeh same here. good mt apps share little and with care.

>  Would it be possible to do
> something like this and have the compiler realize it's safe:
> 
>     class SharedObj
>     {
>         void go() {}
>     }
> 
>     shared Mutex m;
>     shared SharedObj o;
> 
>     static this()
>     {
>         m = new Mutex;
>         o = new SharedObj;
>     }
> 
>     void someFunc()
>     {
>         synchronized( m )
>         {
>             o.go();
>         }
>     }
> 
> > >> 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.
> 
> Java and C++ have cast too, though.  Unfortunately, it's not easy to grep
> for 'cast' in Java because of the syntax, but I use the C++ style casts
> religiously there and I like that they "jump out" at me when reading
> the code.  From a quick scan of an old project of mine, outside systems
> code where casting is often necessary as a matter of course, the precious
> few casts in the app are mostly for warning-free comparisons of signed and
> unsigned integers in situations I know the values will be in bounds.  Which
> reminds me... weren't we going to get tighter conversion rules for concrete
> types?  I'd love to have the D compiler yell at me for these things like my
> C++ compiler does.

fuck yeah walt. put me down for that one too.