Will while(true) in a process of real time priority hang OS?

Question

Will an application with an infinite loop hang the operating system if the application process has real time priority? Should I expect the same behavior on Linux, Windows and Mac OS?

Answer 1

Even for a critical process, you shouldn't run an infinite loop without providing other threads a way to be executed too. For example, by using Thread.yield or Thread.sleep. So, if coded carefully, a real-time prioritized thread shouldn't hang the machine.

Also, keep in mind that threads are not guaranteed to behave equally on all Operating Systems, because at the end of the day, the JVM uses the native OS threads.

Answer 2

Such a process will not hang on Windows; it will still get preempted from time to time to service other processes.

Edit: especially on a dual core CPU or higher, the effects of such a process' presence will be minimal. The CPU is doing almost nothing all the time anyway; even if the real-time process gets 99.5% CPU that still leaves way enough to handle the basic UI tasks like switching between applications.

Answer 3

It will not completely hang OS, but since other processes don't usually have realtime priority they will be given very little CPU time and almost nothing will be executed except the realtime program.

Answer 4

You shouldn't put yourself in a situation where you can't get out of your code gracefully unless you know it will behave as you expected. This practice was used mainly in menus in a console applications and there was a way to exit the application gracefully as expected by pressing for instance the letter Q to Quit the application. This time, you could anticipate and guarantee the final behaviour.

Though it shouldn't hang the OS but your application itself, and as your application requires CPU time, this will somehow paralize resources as the CPU will come and go to process your code. So, this is really unadvisable unless you really do know what you're doing depending on your particular situation.

As the threads are handled by the OS, this practice may behave differently from an architecture to another.

Answer 5

None of those OSs are realtime systems, so from time to time other processes will be spared a few cycles - especially if the processes wake up on external events (e.g. reading from a socket/input device etc.).

For all practical purposes, I can tell from experience that at least linux will appear completely hung(for a 1 processor machine) if you enter an infinitive loop in a process with realtime priority - as the cycles given to other processes are too few to do anyting sensible.

Answer 6

[This is written from theory, and not tested!]

Firstly, you should not expect the same behaviour from all operating systems. Some operating systems do not use pre-emptive multitasking, although modem Mac, Windows and Linux all do.

Vista and Windows 2000 are based on the Windows NT multilevel feedback queue. [Ref]

According to a (dated) TechNet article:

The range of priorities is divided in half with the upper 16 reserved for real-time threads and the lower 16 reserved for variable priority threads. The range of priorities is divided in half with the upper 16 reserved for real-time threads and the lower 16 reserved for variable priority threads.

Real-time threads run at the same priority for their entire lifetime. They are commonly used to monitor or control systems that require action to be taken at very precise intervals. These threads run at higher priorities than all variable priority threads, which means that they must be used sparingly.

So, if you use one of the lower-level real-time threads, it will give up the CPU for higher-level real-time threads. If you choose the highest possible priority, it isn't clear to me what will happen.

Answer 7

In my real-time operating system (RTOS) work, tasks (threads, really) almost always have a while(true) loop, unless they are temporary tasks that will get killed off at some point.

The trick is to make sure that you use while(true) as little as possible, and that you carefully go through everything in those loops to make sure they won't run away. Typically, the first thing in one of these loops is "block on semaphore (or file input or whatever), waiting for something to do." You do this as the first thing so you can't accidentally skip over it with a continue.

In an RTOS, if a thread of a certain priority is executing, unless it blocks, nothing with a lower priority will execute. (This is different from normal OS's where priority is more a thumb on the scales.) So, typically, I'll create a lowest-priority system monitor task that checks system health (make sure the progress variables are moving fast enough, that kind of thing), and if everything is okay, it resets the watchdog timer and goes back to sleep until time for the next check.

Sometimes I'll put in a PWM algorithm in this maintenance task to drive an LED and make it "throb" like the power lights in Macs do when you put them to sleep; when tasks start eating a lot of CPU time, this task gets starved for time and the LED updating gets choppy. If something runs away, the LED sticks full-on or full-off. It's a simple sanity check.

The moral of the story: assume that while(true) can hang something, and make it painful to debug. Minimize its use, and carefully check any code that uses it.