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

[Andrei Alexandrescu]

I got what you meant, but in the general case we need to address all 
possibilities.

So, I think a correct rule is: a shared field is as unwieldy as a global 
shared. Right?


Andrei

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