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

[Sean Kelly]

On Jan 4, 2010, at 5:00 PM, Andrei Alexandrescu wrote:

> Sean Kelly wrote:
> 
>> The only catch with the approach above (and you've mentioned this before) is:
>>    class A {
>>        void fnA() shared { x = 5; }
>>        void fnB() synchronized { x = 6; }
>>        int x;
>>    }
>> I had thought that explicitly labeling variables as shared would sidestep this by requiring ops on the vars to always be atomic.  An alternative (as you've said before) would be to not allow shared and synchronized methods to both be used in a class, but it's pretty common that I'll want to do something like this:
>>    class A {
>>        void fnA() synchronized { sharedWrite( flag, true ); }
>>        void fnB() shared { return sharedRead( flag ); }
>>        shared flag;
>>    }
>> Maybe my explicitly declaring flag as shared somehow provides an exemption?  Or did you have another idea for a way around this?
> 
> Hmmm... if a field is shared in a non-shared object, it means you're not using object's own lock to control access to that field. (You can e.g. assume that other threads have the address of that field.) So that field, inside a synchronized method, will not benefit of the tail-shared exemption and will be subjected to all limitations specific to e.g. a shared global bool.

I meant in a shared instance of A.  Basically, most of my uses of shared amount to setting a value that I want to be read lock-free by the user.  I often don't even care about a prompt update of the field, so long as it happens eventually.  I generally just don't want to pay for a lock or possibly deal with contention to read an often checked but rarely changed value.