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

[Walter Bright]

I figure that the main way to do multithreaded programming in D will be 
with the message passing library that Sean is building. A user using 
that should never see shared. Shared is for those cases that cannot be 
done with message passing.

I think Go's channels are just message passing. The fundamental problem 
with it in Go is Go has no concept of immutability, so there's no way to 
guarantee safety.

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