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

[Sean Kelly]

Yup.

On Jan 4, 2010, at 6:21 PM, Andrei Alexandrescu wrote:

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