[dmd-concurrency] draft 7

[Andrei Alexandrescu]

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?

> Page 28 Comments:
> The limitations on internal data should be mentioned.
> - Can private members be accessed by other functions/etc inside
> BankAccount's module

No. I forgot to mention that. It's the one place where the compiler 
strenghtens private from module-level to class-level.

> - Do member have to be private? Can they be protected? Public?

Undecided.

> - 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().

> - Are arrays and associative arrays supported?

Arrays, yes. Associative arrays, I don't know.

> 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?

> Page 30 Last P: "Inside a method of BankAccount, _parent must be
> considered of type shared(BankAccount).": Did you mean _issuer and Bank?
> 
> Page 32 P2: "It is not impossible the issue might be revisited later":
> impossible the => impossible and the

I meant something like "it's not impossible that the issue" but probably 
I'll rephrase.


Thanks,

Andrei