For the most part,
the "main line" code of a process does not need to be
concerned with the I/O
to message files using software interrupts. As long
as interrupts are enabled,
they can occur anywhere in user code. If one
occurs during an MPE/iX intrinsic, the interrupt is postponed until
you exit the intrinsic and re-enter the process' code.
There are some exceptions. Interrupts can occur
during a "generalized" IOWAIT, during an IOWAIT on
another message file not using software interrupts,
or during a PAUSE.
The use of software interrupts
introduces the possibility of a problem
that applications normally do not have to think about.
Some code is sensitive
to interrupts.
The problem usually occurs with data that is altered by both the
interrupt handler and the main line code.
For example, suppose the main line code
decrements a counter
and the interrupt handler increments the same counter.
The main line code loads
the old value and subtracts one from it. Before
it is stored back, an interrupt occurs.
The interrupt handler loads the old
value,
increments it,
and stores the new value back. The main line code
resumes,
storing its new value
on top of the interrupt handler's new value, and
the increment is lost.
One solution is to protect sensitive code by using
FINTSTATE (FALSE)
to disable interrupts before the operations and
FINTSTATE (TRUE) to enable interrupts afterwards.
