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

[Graham St Jack]

What is the plan to stop "shared" from spreading through all of an 
application's code?

My own preference is to adopt an approach that severely limits the 
number of shared objects, perhaps by using a keyword like "shareable 
that means: "this object is shared, but it is completely ok to call its 
synchronized methods from non-shared methods/objects".

This approach facilitates message-passing, and can very simply handle 
plenty of multi-threaded use-cases. A shareable object whose externally 
accessible methods are all synchronized and DO NOT accept or return any 
references to mutable data should be callable from any thread with 
complete safety, WITHOUT polluting the calling code with "shared".

Within such a shareable object, we can use low-level stuff like mutexes, 
semaphores and conditions to build the desired behaviour, wrapping it up 
and presenting a clean interface.

Re synchronized containers - I don't like the idea at all. That is going 
down the path of having many shared objects, which is notoriously 
difficult to get right, especially for non-experts. IMO, shared objects 
should be small in number, and serve as boundaries between threads, 
which otherwise play in their own separate sand-pits.

Dare I say it - go's emphasis on channels is very appealing to me, and 
should be something that is easy to do in D - even though it is too 
limiting to have it as the only tool in the box.

Thanks,
Graham.

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