[dmd-concurrency] draft 7

[Robert Jacques]

On Mon, 01 Feb 2010 15:09:53 -0500, Andrei Alexandrescu  
<andrei at erdani.com> wrote:
> Robert Jacques wrote:
>> Page 24, P1: "The notable absent is real, which is the only a platform
>> dependent type that the implementation has discretion regarding atomic
>> sharing."
>> which is the only a platform dependent type => which is a platform
>> dependent type
>>  Page 28, P3: "good ole days of classic multithreading;"
>> ole => old
>
> Isn't "good ole" an Americanism?

You're right. It appears to be a regional contraction/variant/slang of  
old, like ol' and has been in use since 1832. But it appear it's mostly  
used when writing dialogue in a specific accent and not in formal prose.  
*shrug* I think old gets the point across and won't confuse non-Americans  
and non-English speakers.

>> Page 28 Comments:
[snip]
>> - Would a transfer function like this be possible?
>>     synchronized class BankAccount {
>>       private double _balance;
>>       void transfer(BankAccount dst, double amount) {
>>         enforce(_balance >= amount);
>>         _balance     -= amount;
>>         dst._balance += amount;
>>       }
>>     }
>>     or would you have to do it like the later example?
>
> Relaxation of field typechecking only happens for "this", not for other  
> objects. If the above were allowed, it would only lock one object.
>
> Now, say you use atomic add for dst. In that case, you can implement  
> transfer as above. It would be a mild violation of encapsulation because  
> you deposit without calling deposit().

Even if you used an atomic add for dst you'd still get a race. Consider,  
thread A tries to deposit to dst and so takes a lock and reads  
dst._balance. Then thread B tries to transfer to dst and commits an atomic  
add. When thread A writes the updated balance back to dst._balance, the  
transfer is over-written and lost.

[snip]
>> Section 1.14.1 Comments:
>> If a reference to data protected by synchronization escapes, then races
>> can and will occur. This seems like a fundamental flaw in the design. I
>> think a cast should be required to enable an escape.
>
> Low-level races won't occur because at most you escape references to  
> shared values. No?

See the transfer example above. This is a variant of the problem with STM  
designs which which Walter posted a link to in January. In essence, a  
value protected by a lock my always be protected by that lock.
http://www.bluebytesoftware.com/blog/Default.aspx#a4cfad7df-ed84-46a4-a961-54aafdaeb9d7

[snip]