Re: extended dual threading [was: Re: Lua in Parallel System]

["Ashwin Hirschi" <deery@...>]

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

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!

Ashwin.
--
no signature is a signature.