[dmd-concurrency] draft 7

[Fawzi Mohamed]

> I suggest we resume and start with describing what was unclear, then  
> specifying the steps we need to take to clarify things better in the  
> draft. Thanks!

p 26-27
"All operations on _balance are now protected by acquiring _guard. It  
may seem
there is no need to protect balance with _guard because a double can  
be read atomi-
cally, but protection must be there for subtle reasons that shall come  
forth later. In brief,
due to today’s aggressive optimizing compilers and relaxed memory  
models, all access
to shared data must entail some handshake between threads; no  
handshake means a
thread could call obj.balance repeatedly and always get a cached copy  
form some pro-
cessor’s cache that never, ever gets updated, in spite of other  
threads’ frenetic use of
deposit and withdraw. ( This is one of the ways in which modern  
multithreading defies
intuition and confuses programmers versed in classic multithreading.)"

 From the previous discussion it should be clear that as written it is  
wrong.
Indeed it is better to have a barrier there (if the update would not  
be atomic, in general case) but there is no need for it in this  
specific case, as access is atomic.
It is wrong that a cache of a processor might be never updated, it  
will be updated at some point, and a barrier (in general) will not  
force the update to be performed immediately.
A problem that can come up is that the variable is promoted to a  
register in a loop and is not updated from the memory.
To avoid this one can use volatile. This issue is a priory  
disconnected with the presence of barriers (well one would hope that a  
correct compiler disables "upgrading to registers" for variables in a  
locked section crossing the boundary of it, but a priory it doesn't  
have to be like that, and especially using just memory barriers, I  
would not trust current compilers to always do the correct thing  
without a "volatile".

Fawzi