[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