[dmd-concurrency] A synchronized storage class?

[Sean Kelly]

Yeah, this is how I thought shared would work, and I like it better  
than the "compiler figures everything out" approach.

Sent from my iPhone

On Jan 7, 2010, at 6:48 AM, Michel Fortin <michel.fortin at michelf.com>  
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.
>
> 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.
>
> -- 
> Michel Fortin
> michel.fortin at michelf.com
> http://michelf.com/
>
>
>
> _______________________________________________
> dmd-concurrency mailing list
> dmd-concurrency at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-concurrency