On Sat, 30 Jan 2010 09:56:57 -0500, Michel Fortin <michel.fortin at michelf.com> wrote:

> Le 2010-01-29 ? 21:04, Andrei Alexandrescu a ?crit :
>
>> Michel Fortin wrote:
>>> Le 2010-01-29 ? 18:03, Andrei Alexandrescu a ?crit :
>> [snip approval]
>>
>> Wow. This proposal has a chance of going through the Senate rather easily :o).
>
> Perhaps. What I meant is that it looks nice and I have no objection. Still, it changes a few things, so we'll have to check all the implications.
>
> For instance, a member function that only access immutable members doesn't need to be synchronized. Or a member function that does not access any variable of the class. Such functions could avoid synchronization automatically in the current scheme *if* synchronization is done in the function and not at the call site.
>
> You were previously thinking about synchronizing at the call site. What do you think of that now?
>
>
>>> Also, what happens if you have a shared variable in your synchronized class?
>>
>> It doesn't matter because synchronized class objects are shared anyway. Shared is therefore redundant.
>
> I think if a variable is explicitly marked 'shared', access to it should not be synchronized. Two reasons:
>
> 1. You can't really pass this variable around to other threads if it requires synchronization. You can only pass the whole object. So this 'shared' variable doesn't really have shared semantics if it is synchronized.
>
> 2. You may want to have a variable with atomic access alongside a synchronized class. If you were doing reference counting for instance, having to acquire a lock to increment/decrement the counter would be annoying.

I agree with you, but I thought the comment was on inherited classes, not member variables. I mean, under your interpretation shared/synchronized classes wouldn't be allowed to access immutable data. And races would abound since an object lock doesn't protect all instances of its member variables. Or maybe I'm reading your comment wrong.

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.

Sean Kelly wrote:
>> 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; } ?

The compiler is able to eliminate locks through analysis. But I'm sure you know a barrier is still needed :o).

Andrei

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

On Jan 31, 2010, at 10:49 PM, Andrei Alexandrescu wrote:

> Sean Kelly wrote:
>>> 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; } ?
> 
> The compiler is able to eliminate locks through analysis. But I'm sure you know a barrier is still needed :o).

Okay, that's what I figured.  Just wanted to verify that this was possible :-)