[dmd-concurrency] A synchronized storage class?

[Sean Kelly]

Forget I said that.  T would be shared, not the shared_ptr.  As long  
as the shared property can be determined at compile-time, then it  
doesn't matter.

Sent from my iPhone

On Jan 7, 2010, at 7:11 AM, Sean Kelly <sean at invisibleduck.org> wrote:

> 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
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency