[dmd-concurrency] draft 7

[Andrei Alexandrescu]

Robert Jacques wrote:
> 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 

my => may or must?

Andrei