[dmd-concurrency] shared arrays, real, shared classes, synchronized classes

[Sean Kelly]

On Jan 29, 2010, at 3:03 PM, Andrei Alexandrescu wrote:

> Walter and I just talked over the phone and agreed on the following. Of course the decisions are not final and are up for debate.
> 
> 1. Atomic array assignment is in.
> 
> We discussed that and concluded the following:
> 
> * CMPXCHG16B and friends are the norm of modern Intel-like machines, and are unlikely to go away soon. We are designing D for the future and the future looks like two-word assignment is in it.
> 
> * Pre-2004 AMDs and probably some other chips still lack two-word assignment. We decided that we will look for creative solutions to those problems as they come up (hat tip to Kevin's idea of using a spin lock).

Works for me.

> 2. Atomic assignment of real is still undecided.
> 
> I think I'll write in TDPL that it's platform dependent. Assignment to 80-bit reals on 32-bit machines is still problematic.

It pretty much has to be platform dependent, since the size of a real is platform dependent.

> 3. There are _no_ more synchronized or shared methods. That is, code like this is incorrect:
> 
> class A { void fun() shared { } }
> class B { void fun() synchronized { } }
> 
> Rationale: it is tenuous to offer mixed modes in the same class.

Does the synchronized statement still exist?

> 4. The "synchronized" attribute is hoisted at class level:
> 
> synchronized class A { ... }
> 
> That means each and every method of that class is synchronized.

Much clearer, and it neatly eliminates all the weirdness with shared and synchronized methods interacting.  I assume these classes can still contain explicitly shared data?  Is there any way around locking for get() { return shared_x; } ?

> 5. The "shared" attribute is hoisted at class or struct level:
> 
> shared class A { ... }
> shared struct B { ... }
> 
> That means the implementation is lock-free and uses its own synchronization mechanisms.

Can the class contain any synchronized statements (assuming they still exist)?  I'm guessing no, and that shared classes and structs will be rare.

> 6. When defining an object of a synchronized of shared type, you still need to qualify it with "shared" in order to make it so. For example:
> 
> synchronized class A { ... }
> shared A a; // fine
> A b;        // error

Seems kind of weird, but I guess it makes sense.  I'll have to think about it some more.