 |
lua-l archive |
|
|
||
|
On Feb 12, 2005, at 01:58, Ashwin Hirschi wrote:
The one "issue" I could see with your approach is that reading the signal tested in the line hook actually depends on memory synchronization and doing that properly is almost as expensive as a mutex lock/unlock. Is this not anissue because you potentially just churn through enough memory that eventually the value gets propagated?The approach I've implemented simply has the line hook code test a (zero/non-zero) flag variable.
The issue that Mark is talking about (I think) comes up on machines with more than processor. The thread that sets the flag to 1 may be on a different processor to the thread that is reading it. It can take arbitrarily long for effects of the write to the memory location that is executed on one processor to be seen on another processor. In actual practice it can be anything from almost instantly to basically forever.
On relaxed memory order architectures (Alpha, Sparc v9 in certain modes, maybe others), where a processor writes to memory in a different order than the instructions get executed, you may need a barrier. Basically if you are relying on the flag being set to 1 indicating that some other piece of memory is in a certain state, then you'll need a write barrier before setting it to 1.
David Jones