OSDev.org

Brendan wrote:

bewing wrote:To postulate a situation where one process is requiring that much CPU time, and all other processes are completely idle is a) ridiculous, and b) a situation where it is quite acceptable for an OS to provide less than 100% performance from the hardware. (However, if it is vital to create such a gluttonous app, then the programmer should create it as multiple processes in idependent address spaces, communicating via IPC or the filesystem, if necessary.)

Huh? A situation where one process is requiring that much CPU time, and all other processes are completely idle is a) extremely likely. Think of something like a ray-tracer, where the frame being generated is divided into n areas for n CPUs. You could try to force something like this to use multiple processes instead of just using multiple threads, but in this case it'd just end up using shared memory mappings which ends up being almost identical to multi-threaded anyway (and if your OS doesn't support shared memory mappings, then they'll find a different OS that does let them use all the CPUs).

Indeed. Extremely likely. What's worse, that situation can also be real-time critical; doing music on a computer means you probably have more than enough CPU hungry plugins running to fill not just one CPU but sooner or later all cores you might have. Any of the plugins misses a realtime deadline (and about 10ms of buffering latency is pretty much the upper-limit of acceptable here) and you're audio drops, you have no choice other than render some stuff to static audio tracks (known as freeze or bounce) and try again. And if that ever happens live or while recording, you're pretty much screwed.

Even processes like web-browsers typically fit this definition (though aren't realtime critical), at least unless you run each tab in a separate process like Chrome.