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

Andrei Alexandrescu andrei at erdani.com
Mon Jan 4 10:12:22 PST 2010


Michel Fortin wrote:
> Le 2010-01-04 à 11:21, Jason House a écrit :
> 
>> On Jan 4, 2010, at 9:46 AM, Andrei Alexandrescu <andrei at erdani.com>
>> 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.
>> In dmd 2.037, that was not true. Bugzilla 3642 (on diagnostic
>> message) shows sample code where calling A.bar fails on objects of
>> type A.
> 
> And also, if the object is not shared, calling the shared method bar
> could leak a reference to the thread-local object in a variable
> shared with other threads. So I think the compiler is correct in
> rejecting a call to a shared method on a non-shared object. That is,
> unless it can prove the reference doesn't escape the function's
> scope.

You're right, sorry. We've been back and forth on this a couple of 
times. The knee-jerk reaction is that shared is strictly more 
restrictive than non-shared, so it's fine to convert from non-shared to 
shared. But in reality shared and non-shared are in no subtyping 
relationship; a lot of parallels could be drawn with immutable: 
immutable is like shared, const would be like mayormaynotbeshared.

At some point we thought we'd need to add something to the effect of 
mayormaynotbeshared, which would be a supertype of both mutable and 
shared, just like const is a supertype of mutable and shared. We hope to 
get away without it.


Andrei


More information about the dmd-concurrency mailing list