Page 126 - DCAP103_Principle of operating system

Unit 4: Process Management-III

When a thread creates a new thread, semaphore, or other kernel object, the kernel carves Notes
off a chunk of memory from this central store to hold the data for this object. A bug in one
thread could, therefore, result in a situation where this program creates too many kernel
objects and the central store is exhausted (see Figure 4.4 a). A more critical thread could
fail as a result, perhaps with disastrous effects.

In order to guarantee that this scenario cannot occur, the RTOS can provide a memory quota
system wherein the system designer statically defines how much physical memory each
process has (see Figure 4.4 b). For example, a user interface process might be provided a
maximum of 128 KB and a flight control program a maximum of 196 KB. If a thread within
the user interface process encounters the aforementioned failure scenario, the process may
exhaust its own 128 KB of memory. But the flight control program and its 196 KB of memory
are wholly unaffected. In a safety-critical system, memory should be treated as a hard
currency—when a thread wants to create a kernel object, its parent process must provide
a portion of its memory quota to satisfy the request. This kind of space domain protection
should be part of the RTOS design. Central memory stores and discretionarily-assigned
limits are insufficient when guarantees are required.

If an RTOS provides a memory quota system, dynamic loading of low criticality applications
can be tolerated. High criticality applications already running are guaranteed to have the
physical memory they will require to run. In addition, the memory used to hold any new
processes should come from the memory quota of the creating process. If this memory
comes from a central store, then process creation can fail if a malicious or carelessly written
application attempts to create too many new processes. (Most programmers have either
mistakenly executed or at least heard of a Unix “fork bomb,” which can easily take down
an entire system.) In most safety-critical systems, dynamic process creation will simply not
be tolerated at all, and the RTOS should be configurable such that this capability can be
removed from the system.
4.4.6 Guaranteed Resource Availability: Time Domain

The vast majority of RTOSes employ priority-based, preemptive schedulers. Under this scheme,
the highest priority ready thread in the system always gets to use the processor (execute). If
multiple threads are at that same highest priority level, they generally share the processor equally,
via time slicing. The problem with this time slicing (or even run-to-completion) within a given
priority level, is that there is no provision for guaranteeing processor time for critical threads.
Consider the following scenario—the system includes two threads at the same priority level.
Thread A is a non-critical, background thread. Thread B is a critical thread that needs at least
40% of the processor time to get its work done. Because Threads A and B are assigned the same
priority level, the typical scheduler will time slice them so that both threads get 50% of the
processor. At this point, Thread B is able to get its work done. Now suppose Thread A creates
a new thread at the same priority level. Consequently, there are three highest priority threads
sharing the processor. Suddenly, Thread B is only getting 33% of the processor and cannot get
its critical work done. For that matter, if the code in Thread A has a bug or virus, it may create
dozens or even hundreds of “confederate” threads, causing Thread B to get a tiny fraction of
the runtime.
One solution to this problem is to enable the system designer to inform the scheduler of a
thread’s maximum “weight” within the priority level. When a thread creates another equal
priority thread, the creating thread must give up part of its own weight to the new thread. In our
previous example, suppose the system designer had assigned weight to Thread A and Thread B
such that Thread A has 60% of the runtime and Thread B has 40% of the runtime. When Thread
A creates the third thread, it must provide part of its own weight, say 30%. Now Thread A and

LOVELY PROFESSIONAL UNIVERSITY 119