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

[Mark Hamburg <mhamburg@...>]

Mutex locks and unlocks always include a memory sync and/or barrier. This is
what makes them expensive even when there is no contention.

The issue at hand is that if thread A on processor A sets a piece of memory:

    sharedMemory->flag = 1

And thread B on processor B is testing this flag:

    if( sharedMemory->flag ) {
        /* yield time */
    }

And no memory synchronization/barrier exists, then thread B may not see
thread A's changes for an arbitrarily long period of time.

But the whole point is that we don't want to pay for a memory barrier.

I haven't tried it, but my reading of the documentation for pthread_kill
would suggest that one could use it to trigger a signal handler in thread B
from thread A. This would allow thread B to run all out until a signal from
thread A instructed thread B to install a hook proc which would yield a
mutex back to thread A.

Mark

on 2/14/05 4:25 PM, Ashwin Hirschi at deery@operamail.com 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 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.