[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: extended dual threading [was: Re: Lua in Parallel System]
- From: "Ashwin Hirschi" <deery@...>
- Date: Tue, 15 Feb 2005 01:25:42 +0100
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 an 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
Okay, I get it now. If memory synchronization becomes an issue on these architectures it certainly seems necessary to get things in-sync before state access is handed from one party to another.
But, thinking about it: wouldn't such a mechanism then always have to be in-place?
I mean, indirect mutex locking through the LUA API seems inadequate in these situations as well. So, there would be an additional cost there too, right?
Anyway, there have been surprisingly few other reactions to Nelson's original question. Or did I miss something?
I would love to hear about other people's experiences with Lua in threaded/parallel/whatever environments!
no signature is a signature.