[dmd-concurrency] A synchronized storage class?

[Sean Kelly]

Turning off shared in non-shared objects could be useful for fields in  
a shared_ptr.  That would be a struct though, so I'm not sure much of  
this applies anyway.

Sent from my iPhone

On Jan 7, 2010, at 7:00 AM, Andrei Alexandrescu <andrei at erdani.com>  
wrote:

> Michel Fortin wrote:
>> Le 2010-01-07 à 8:54, Andrei Alexandrescu a écrit :
>>> We would very much like to _not_ add new qualifiers unless
>>> absolutely necessary. Your examples don't express that necessity -
>>> if you simply remove the "synchronized" qualifier off i and j, the
>>> compiler has enough information to do what's needed.
>> Sorry, I must be getting tiresome by proposing qualifiers then. I'll
>> refrain from proposing new qualifiers from now on.
>
> It's not tiresome at all. On the contrary, I encourage you to do so  
> if you can demonstrate necessity.
>
>> You're right that the example doesn't show a necessity for
>> "synchronized" qualifying i and j. But I think the essence remains:
>> member variables explicitly written as being "shared" could stay
>> "shared" even under synchronization, forcing you to use atomic
>> operations. Other member variables could be accessible only from
>> not-shared functions and from shared functions under synchronization.
>> This would improve thread safety because each variable would have
>> only one way to be accessed when the object is shared, either under
>> synchronization or with atomic operations, but not both.
>> The downsides are that you can't have a variable which is not shared
>> when the object is not and become "shared but not synchronized" when
>> the object is shared, nor can you synchronize access to shared
>> members in a thread-local object. I don't see how to fix that
>> (without a new storage class), so would those downsides be
>> acceptable? I feel the first one might be too much.
>
> What real-world scenarios would require such a member?
>
>
> Andrei
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency