[dmd-concurrency] draft 7

[Sean Kelly]

On Feb 1, 2010, at 8:41 PM, Fawzi Mohamed wrote:

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

Yup.  It's true that a LOCK prefix triggered a bus lock once upon a time, but it doesn't escape the cache any longer.  This would have been as close to a handshake as I can come up with.

> 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".

Sadly, volatile is deprecated in D 2.0.  You pretty much have to use inline asm and rely on the fact that Walter has said D compilers should never optimize in or across asm code.