[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