[dmd-concurrency] synchronized, shared, and regular methods inside the same class
Sean Kelly
sean at invisibleduck.org
Wed Jan 6 22:34:11 PST 2010
Oops, both. Thread visibility in 1 and access control in 2.
Sent from my iPhone
On Jan 6, 2010, at 8:02 PM, Andrei Alexandrescu <andrei at erdani.com>
wrote:
> I think there's a terminological conflation wrt "visibility". Sean,
> are you talking about thread visibility or about access control?
>
> Andrei
>
> Graham St Jack wrote:
>>> So how about a quick summary to figure out where we are? From
>>> memory, I think it's pretty well established that:
>>>
>>> 1. shared denotes visibility. A global shared variable is visible
>>> from all threads, an unlabeled variable is thread-local.
>>> 2. Attaching the shared property to a class instance affects
>>> method visibility. shared and synchronized methods are visible,
>>> unlabeled ones are not.
>>> 3. Attaching the shared property to a value makes that value
>>> effectively atomic. All access and mutation is accomplished via
>>> library calls.
>>>
>>> I think there was some concern about the shared property of a
>>> class instance automatically extending to all of its fields. Were
>>> there other concerns as well? I know that Jason had mentioned
>>> issues with non-statically verifiable shared semantics in general,
>>> but that's another ball of wax entirely.
>>> _______________________________________________
>>>
>> I am assuming that item 2 includes the idea of unlabelled methods
>> being callable from methods of the shared instance.
>> _______________________________________________
>> 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
More information about the dmd-concurrency
mailing list