[snvzz]

The keyword being latency.

Even a powerful PC, such as running WinNT or Linux on my 9800x3d, doesn't feel as tight as my pretty basic Amiga 500 does.

It's the difference between a RTOS proper (AmigaOS, QNX, BeOS) and a toy (Windows, Linux, MacOS).

[mnw21cam]

AmigaOS couldn't be described as a RTOS proper, not like QNX. For one, it had a forbid() system call which would stop the scheduler from pre-empting the current running process. It had no guarantees on latency, which is the essence of a RTOS.

It had a very simple static absolute priority scheduler and very little that could cause long pauses (like virtual memory), which made it much more predictable in scheduling than more sophisticated schedulers like in Windows, Linux, and MacOS. At one point I had an A1200 and a Linux Pentium 300-ish, and CD-writer on both systems. I could trust the Amiga to write CDs without creating a coaster every time, where the Linux box would succeed only 2/3 the time due to the unpredictable scheduling and it running the buffer dry.

So it wasn't a real RTOS, but it definitely behaved more like one that what we have now.

[snvzz]

>For one, it had a forbid() system call which would stop the scheduler from pre-empting the current running process.

This is, by the way, equivalent to SCHED_FIFO on Linux.

There are very legitimate reasons a hard realtime task may need to be non-interruptable.

[stormking]

There was a Shareware tool called Executive that would manipulate task priorities to, amongst other things, prioritize the active application.

[mnw21cam]

That particular tool's purpose was actually to shift the Amiga's very simple RTOS-like static priority scheduler more towards a more complex fairness-based scheduler like Linux/Windows currently has, making it less real-time than before. Yes, you could make rules that could elevate certain tasks by name matching automatically, giving you more control and predictability, but that's not something you couldn't already do.