[dmd-concurrency] A synchronized storage class?

Andrei Alexandrescu andrei at erdani.com
Thu Jan 7 07:00:40 PST 2010


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


More information about the dmd-concurrency mailing list