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

[Andrei Alexandrescu]

Answers to the other questions coming with the next draft btw.

Andrei

Sean Kelly wrote:
> 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.
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency