Interrupts and mutual exclusion
karl bezzoto
I have threequestions:
Q1) is it possible to disable/enable interrupts from a high level
language? I expect no but i saw on the web some c code showing how to
do this. Is this code used only in the absence of an operating system?
Q2) sempahores might be implemented by enabling/disabling interrupts.
does this mean naturally concurrent libraries run on kernel mode?
Hence calling underneath a kernel semaphore? what about Java
concurrency API
Q3) are the instructionS such as testandset, swap made atomic via
disabling/enabling interrupts?
Cheers and sorry for the non-technical wording of my questions.
David Schwartz
> Q1) is it possible to disable/enable interrupts from a high level
> language? I expect no but i saw on the web some c code showing how to
> do this. Is this code used only in the absence of an operating system?
Q1: Yes it is. But it's not practical to do it unless you *are* the
operating system. Kernels can be written in C and can disable and
enable interrupts as needed.
> Q2) sempahores might be implemented by enabling/disabling interrupts.
> does this mean naturally concurrent libraries run on kernel mode?
> Hence calling underneath a kernel semaphore? what about Java
> concurrency API
Q2: If you are implementing semaphores entirely in user space, then
you won't implement them by enabling/disabling interrupts. On most
modern CPUs, it is possible to implement concurrent primitives like
semaphores and locks without needing any special privileges (such as
disabling interrupts). For implementations that have special
privileges anyway, such as kernel implementations, you can do so if
it's helpful.
The Java concurrency API will be implemented as part of the Java JVM
using whatever works best on the particular platform. On most
platforms, it uses the normal concurrency primitives for that
platform, though it can use "optimized" primitives on CPUs where
that's possible. This includes all modern CPUs, but just because it's
possible doesn't mean it's smart.
> Q3) are the instructionS such as testandset, swap made atomic via
> disabling/enabling interrupts?
On modern CPUs, even the non-atomic versions of those instructions
cannot be interrupted. So interrupts are not what's preventing them
from being atomic. Atomicity on a "test and set" or "swap" operation
requires preventing other CPUs from getting at the memory "in the
middle" of the operation, which is a problem that can't be solved by
disabling interrupts.
The simplest atomic operation would be an atomic increment. The need
for atomicity is that two increments on two different CPUs don't
result in readA, readB, increment A, incrementB, writeB thus resulting
in only one increment. Interrupts don't cause this problem, so
disabling interrupts can't solve it. (Plus, no modern CPU makes 'fast'
instructions like read/modify/write or test/set interruptible anyway.)
DS
Marcel Müller
karl bezzoto wrote:
> Q2) sempahores might be implemented by enabling/disabling interrupts.
no. Disabling IRQs is neither necessary nor sufficient. Think about
multi core CPUs.
> does this mean naturally concurrent libraries run on kernel mode?
No.
> Hence calling underneath a kernel semaphore?
Either this or using implicitly atomic instruction of the current
platform. If the synchronization should be used as IPC, in fact only the
kernel functions are an option.
> Q3) are the instructionS such as testandset, swap made atomic via
> disabling/enabling interrupts?
No. That won't help on SMP machines.
These atomic instructions are synchronized at the level of the cache and
memory controller.
Marcel