[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: extended dual threading [was: Re: Lua in Parallel System]
- From: David Jones <drj@...>
- Date: Sat, 12 Feb 2005 10:07:21 +0000
On Feb 12, 2005, at 01:58, Ashwin Hirschi wrote:
The one "issue" I could see with your approach is that reading the
tested in the line hook actually depends on memory synchronization
that properly is almost as expensive as a mutex lock/unlock. Is this
issue 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
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.