[dmd-concurrency] shared arrays, real, shared classes, synchronized classes

[Robert Jacques]

On Sat, 30 Jan 2010 09:56:57 -0500, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> Le 2010-01-29 à 21:04, Andrei Alexandrescu a écrit :
>
>> Michel Fortin wrote:
>>> Le 2010-01-29 à 18:03, Andrei Alexandrescu a écrit :
>> [snip approval]
>>
>> Wow. This proposal has a chance of going through the Senate rather
>> easily :o).
>
> Perhaps. What I meant is that it looks nice and I have no objection.  
> Still, it changes a few things, so we'll have to check all the  
> implications.
>
> For instance, a member function that only access immutable members  
> doesn't need to be synchronized. Or a member function that does not  
> access any variable of the class. Such functions could avoid  
> synchronization automatically in the current scheme *if* synchronization  
> is done in the function and not at the call site.
>
> You were previously thinking about synchronizing at the call site. What  
> do you think of that now?
>
>
>>> Also, what happens if you have a shared variable in your synchronized
>>> class?
>>
>> It doesn't matter because synchronized class objects are shared anyway.
>> Shared is therefore redundant.
>
> I think if a variable is explicitly marked 'shared', access to it should  
> not be synchronized. Two reasons:
>
> 1. You can't really pass this variable around to other threads if it  
> requires synchronization. You can only pass the whole object. So this  
> 'shared' variable doesn't really have shared semantics if it is  
> synchronized.
>
> 2. You may want to have a variable with atomic access alongside a  
> synchronized class. If you were doing reference counting for instance,  
> having to acquire a lock to increment/decrement the counter would be  
> annoying.

I agree with you, but I thought the comment was on inherited classes, not  
member variables. I mean, under your interpretation shared/synchronized  
classes wouldn't be allowed to access immutable data. And races would  
abound since an object lock doesn't protect all instances of its member  
variables. Or maybe I'm reading your comment wrong.