[dmd-concurrency] synchronized, shared, and regular methods inside the same class

[Andrei Alexandrescu]

This may be easiest to answer for people with extensive experience with 
Java's threading model. Consider the following D code:

class A {
     void foo() synchronized;
     void bar() shared;
     void baz();
}

If we have an object of type A, all three methods are callable. If we 
have an object of type shared(A), baz() is not callable. There is a 
remaining problem with foo() and bar(): the first uses lock-based 
synchronization, the second uses a sort of free threading (e.g. 
lock-free) that the compiler is unable to control. It follows that calls 
to foo() and bar() from different threads may easily create race conditions.

I think the compiler should enforce that a class either defines 
synchronized methods, shared methods, but not both. So the class writer 
must decide upfront whether they use lock-based or lock-free threading 
with a given class. Does this make sense? Is it too restrictive?

Walter asked - what if we take this one step further and force a class 
to define _all_ methods either synchronized, shared, or neither? In that 
case the keyword could be moved to the top:

shared class A { ... all methods shared ... }
synchronized class B { ... all methods synchronized ... }
class C { ... shared/synchronized not allowed ... }

Has experience with Java shown that it's best to design classes for 
concurrency in separation from single-threaded classes? Effective Java 
doesn't mention that. But then there are all these methods 
synchronizedCollection, synchronizedList etc. that wrap the 
corresponding collections (which probably don't have synchronized 
methods). I'm reading this up, but if there's someone on this list who 
could save us all some time, please chime in.


Thanks,

Andrei