"Pieter Emmelot" <emmelot at e-solutions.demon.nl> wrote:

> | In fact, simply adding a lock around all accesses introduces a deadlock
> | by design: suppose the interpreter is interrupted while it has the lock,
> | and then the interrupt code also tries to obtain the lock.  The
> | interrupt would block, which is a really bad situation.
> 
> Depends on what kind of lock your are using.
> When you use the locking mechanism of the underlying OS the OS will take
> care of such a situation. Look for 'priority inversion' or 'priority
> inheritance' in the docs. Otherwise it wouldn't make sense to have locks at
> all wouldn't it? ;-)
> 

I think you are suggesting that the OS should disallow interrupts while a
lock is held.  True, this would work, if you have proper OS support.  An
alternative solution, though, is to design your system so that
you don't obtain locks inside an interrupt.  This is possible
for Squeak's problem, and makes it really easy on the OS.

Unfortunately I just checked, and it's not the way Squeak actually works currently.

Here's the safe way.  First, have a global flag interruptOccured. 
Second, for each semaphore, allocate some memory at a fixed location to
flag interrupts for that particular semaphore.  Initialize all the flags
to 0.

Now, whenever an interrupt occurs, set the global flag and the flag for
the relevant semaphore to 1.  And now, when the interpreter does its
check for interrupts, it can check the global flag, and if set, it can
check all the individual flags.  When it finds an individual flag which
is set to 1, then it signals the semaphore for that flag.


Squeak is currently doing something different.  There seems to be a queue of
pending interrupts, and the signalSemaphore() code just adds something to the
end of the queue.  Indeed, this is not safe without locking.  Consider the following
line from the current implementation:

	   semaphoresToSignalCount += 1;


If context switching happens at the worst time, then two contexts could
use the same value of semaphoresToSignalCount and thus an interrupt will
end up being dropped.


So if you don't use locks, the current implementation can drop
interrupts.  If you use locks, then the current implementation is
either useless from interrupts, or requires special OS support.
The scheme I described doesn't have these limitations.


Lex