[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