|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> The OS was arranged so that you could swap out several processes (for want
> of a better word) and swap in another set all without rotational latency or
> talking to the CPU.
As I understand it (something I remember from the University), the most
reliable mainframes are quite complicated on both hardware and software
(well, the operating system) with respect to the CPUs (if there are multiple,
redundant CPUs which ensure uninterrupted uptime even if a CPU malfunctions).
If a CPU suddenly gets fried, first the hardware and then the OS have to
detect this and then the OS has to transparently transfer the process which
was currently being run on that faulty CPU to another one, *without the
program breaking* (in other words, the program doesn't even notice that
something went wrong).
I suppose that in the good old days when there were no caches nor
pipelines to speak of, this is relatively easy, as the OS could probably
keep track of the exact instruction where the process was going, and
simply "simulate" a context switch when it gets the signal that the CPU
went dead, and then transfer the process to another CPU as usual. However,
I assume that with modern CPUs, with all the parallel pipelines, microcodes,
out-of-order execution and such, this becomes quite a big challenge (and
probably makes the CPU design quite a lot more complicated, if it has to
be prepared for malfunction in this way).
That's the reason why you can't simply use a PC as a reliable mainframe.
I don't think Intel processors support anything like this. If a CPU fries,
you are more or less toast. (Or, in other words, you are going down, no
matter what, especially if the malfunction happens when the CPU is
executing some critical kernel code.)
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |