Why disabling interrupts for mutual exclusion works only for uniprocessor systems?

[Disc Magnet]

In an advanced operating systems book, the following was written under
the section called "Early Mechanisms for Mutual Exclusion":

"Disabling interrupts, another mechanism that achieves mutual
exclusion, is a mechanism where a process disables interrupts before
entering the critical section and enables the interrupt immediately
after exiting the critical section. Mutual exclusions is achieved
because a process is not interrupted during the execution of its
critical section and thus excludes all other processes from entering
their critical section. The problems with this method are that it is
applicable to only uniprocessor systems and important input-output
events may be mishandled."

I would like to know why this method is applicable to only
uniprocessor systems. Why can't this method by applied to
multiprocessor systems?

[Bluemoon]

In multi-processor system, each CPU/core execute code simultaneously,
so whether the current CPU has disabled interrupts has nothing to do
to avoid other CPU from entering the same region.

[Rod Pemberton]

"Disc Magnet" <discm...@gmail.com> wrote in message
news:03348329-a32f-4dc1...@v12g2000vbx.googlegroups.com...

AIUI, they could've, but it could potentially cause serious problems. On a
uniprocessor or single core processor, disabling interrupts disables
interrupts for the entire system until the programmer re-enables interrupts.
But, as Bluemoon said, in a multi core cpu, disabling interrupts only
applies to that specific core not the entire system. If one core could
disable interrupts for the entire system, and you have, let's say 4 cores
executing the same code and that code disables interrupts for a block of
instructions but this occurs at different times for each of the cores, then
it's possible that interrupts might not ever be re-enabled for the system,
or wouldn't be enabled long enough to handle interrupt events. So, they
generally come up with some other special instruction that's "atomic" which
can be used to block the other cores, but only for a single instruction
cycle, not for a large block of code like enabling/disabling interrupts.
I.e., the lock-out time is limited to a single cycle, and the programmer
cannot create large blocks of code which are locked out for long time
periods. In theory, that'll prevent the lock-out situation.

Rod Pemberton

[Maxim S. Shatskih]

> I would like to know why this method is applicable to only
> uniprocessor systems. Why can't this method by applied to
> multiprocessor systems?

Because CLI on one CPU does not alter the state of another CPUs, and another CPUs are free to execute the "sensitive" code while CPU 0 is CLIed.

This is why Windows pre-Vista used uniprocessor and multiprocessor kernel builds. On UP, the spinlock is just plain KeRaiseIrql(DISPATCH_LEVEL) (thing similar a bit to CLI). On SMP, the spinlock is the real spinlock.

--
Maxim S. Shatskih
Windows DDK MVP
ma...@storagecraft.com
http://www.storagecraft.com

[Bluemoon]

On Dec 16, 5:20 am, "Maxim S. Shatskih"

As a side note, even if all the core disabled interrupts, they can
still execute in parallel and thus cannot be mutually excluded.
The usual implementation of spinlock in multiprocessor system uses an
memory and with the bus lock mechanism
The spinlock I used is like this:

spinlock:
bt dword [esp+4], 1
pause
jc spinlock
lock bts dword [esp+4], 1
jc spinlock
ret

the LOCK prefix ensure only one CPU can access the desired memory and
provide the ground for exclusion.

Thanks.