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

[Jason House]

On Jan 4, 2010, at 11:31 AM, Sean Kelly <sean at invisibleduck.org> wrote:

> On Jan 4, 2010, at 6:46 AM, 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'll admit that I'm leery of having shared methods in general.   
> Operations occurring in order can still easily produce unexpected  
> results when multiple threads are interleaving execution.  Consider  
> increment, for example: if "x++" is executed as "x = x + 1" (ie. a  
> load, add, and a store).  I know that lock-free variables are  
> somewhat of a separate topic, but I wanted to mention this now anyway.

Sadly, this is a side effect of a simplistic handling of shared.  
Shared is more like "here be dragons, here's an ice cube in case one  
breaths fire on you". Nearly all protection / correctness verification  
are missing and left for D3 or beyond. Message passing lets shared  
aware code remain in the trusted code base...