EPFO APFC 2023 General Studies · Question 49 of 120

Correct — B, (b) Real time. A real-time operating system is defined by exactly the property the stem describes: it must respond to an event within a predetermined time, and the guarantee of that deadline is the design goal the whole system is built around. An ordinary operating system is judged by throughput and by average response — how much work it gets through and how quickly it usually reacts. A real-time system is judged by its worst case. The scheduler is priority-based and pre-emptive, so a higher-priority task takes the processor away from a lower-priority one the moment it becomes ready; interrupt latency is bounded and measured; the kernel is kept small, and features that make timing unpredictable, such as demand paging from a disk, are restricted or removed. The word for the quality being bought is determinism: not speed on average, but a ceiling on how long a response can possibly take. Real-time systems come in two grades. In a hard real-time system a missed deadline is a system failure — flight control, an anti-lock braking system, a cardiac pacemaker, the controller of an industrial robot, a missile guidance system. In a soft real-time system a missed deadline degrades the quality of the result without destroying it, which is the case in audio and video playback, in a live streaming pipeline, and in an online transaction system where a slow response merely annoys. Both are real-time; only the consequence of lateness differs. The systems in service carry the label plainly — VxWorks, QNX, FreeRTOS and RTLinux are the usual examples — and the reason a general-purpose desktop operating system is not among them is not that it is slow, but that nothing in it promises an upper bound on how long a particular task will wait.

• (a)Embedded — This is the nearest miss in the set, and the two categories genuinely overlap. An embedded operating system is one that runs inside a device built for a single purpose — a router, a washing machine, a set-top box, an engine management unit — on fixed hardware with tight limits on memory and power, and often with no general file system or user interface at all. What defines it is where it runs and what it runs on, not any promise about timing. Many embedded systems do have real-time constraints and use a real-time kernel, which is why the two words are so often seen together, but plenty do not: a display controller that repaints a menu a few milliseconds late has failed at nothing. The property named in the stem — a response guaranteed within a predetermined time — belongs to the real-time category by definition, and to the embedded category only when the designer has chosen to add it.
• (c)Multiuser — A multiuser operating system allows several users to work on one machine at the same time, keeping their processes, files and permissions separate — the classic examples being Unix and its descendants on a shared server. Its scheduling is built for fairness and throughput: a time-sharing scheduler gives each user's processes a slice of the processor in turn precisely so that no one is starved, which is the opposite of the strict priority ordering a deadline guarantee requires. It is a category defined by how many people the system serves, not by how fast it must react, and a heavily loaded multiuser system will happily make everybody wait a little longer rather than break any one task's deadline, because it has no deadlines to break.
• (d)Synchronized — There is no category of operating system called synchronised. The word is real and belongs to the subject — process synchronisation is one of the central problems an operating system solves, using semaphores, mutexes, monitors and critical sections to keep concurrent processes from corrupting shared data, and the classic exercises are the producer-consumer, readers-writers and dining philosophers problems. But synchronisation is a mechanism inside a system rather than a type of system, and the recognised types are batch, multiprogramming, time-sharing, multiprocessing, distributed, network, real-time, embedded and mobile. An option built from a genuine term of art used in the wrong slot is this block's standard distractor, and the defence is to ask whether the word names a kind of operating system or a thing operating systems do.

An operating system manages the processor, the memory, the devices and the files, and the types it is sorted into differ by what the design is optimised for. A batch system takes jobs in groups with no interaction; a multiprogramming system keeps several jobs in memory so the processor never idles while one waits for input or output; a time-sharing system slices the processor between interactive users so each feels served; a multiprocessing system spreads work across more than one processor; a distributed system presents many machines as one; a network operating system manages shared resources across a network; an embedded system runs a single dedicated device; and a real-time system guarantees a response within a stated deadline. The real-time category is the only one whose defining property is a bound on time rather than a way of dividing work, and everything characteristic of it follows from that: priority-based pre-emptive scheduling so the most urgent ready task always holds the processor, a measured and bounded interrupt latency, a small kernel with predictable code paths, and the avoidance of mechanisms whose cost cannot be bounded, such as fetching a page from a disk. The trade is deliberate. A real-time system will often be slower on average than a general-purpose one, because it gives up the optimisations that improve typical performance in exchange for a ceiling on the worst case. Hard real-time treats a missed deadline as a failure; soft real-time treats it as a loss of quality.

The computer block of this paper works through a standard first-course syllabus — programming constructs, markup, operating systems, number systems, networking and hardware — and asks for one named fact at a time. Operating system questions in that style almost always turn on a definition, so the useful preparation is a list of the types with the single property that distinguishes each, learnt in a form short enough to be matched against a stem in ten seconds. That is exactly how this item is built: the stem is a definition with the name removed, and the candidate is asked to supply the name. It is also worth noticing what makes an item like this harder than it looks. Two of the four options, embedded and real-time, describe overlapping populations of real systems, and a candidate who has read that an embedded controller must respond quickly may reasonably hesitate. The resolution is to read the stem as the definition it is — designed to respond within a predetermined time — and ask which category is defined by that property rather than which category often has it.

• A real-time operating system guarantees that a response to an event occurs within a predetermined deadline; determinism, not average speed, is what it optimises.
• It uses priority-based pre-emptive scheduling, bounds its interrupt latency, and avoids mechanisms of unpredictable cost such as demand paging from disk.
• Hard real-time systems treat a missed deadline as a failure — flight control, anti-lock braking, pacemakers, industrial robots; soft real-time systems merely lose quality, as in audio and video playback.
• VxWorks, QNX, FreeRTOS and RTLinux are standard examples of real-time operating systems.
• An embedded operating system is defined by running a dedicated device on fixed, limited hardware; it may or may not carry real-time guarantees.
• A multiuser or time-sharing system schedules for fairness and throughput among users, which is a different goal from bounding the response time of any single task.
• Synchronisation is a mechanism inside an operating system — semaphores, mutexes, monitors, critical sections — and not a type of operating system.

• Choosing embedded because embedded devices are associated with fast reaction; the stem states a guaranteed deadline, which is the definition of real-time and only an option for an embedded design
• Assuming a real-time system is simply a fast system; it is a predictable one, and it may be slower on average than a general-purpose system
• Confusing multiuser with multitasking — one is about how many people the system serves, the other about how many tasks run at once
• Accepting an option because the word is a genuine term in the subject; synchronisation belongs to operating systems without being a kind of operating system
• Forgetting that soft real-time is still real-time; the grade of the guarantee changes, not the category

Operating system items in this paper are definition-matching questions with one-word options, and the distractors are neighbouring categories rather than nonsense. Expect an overlapping category to be offered alongside the correct one, and expect at least one option that names a mechanism inside operating systems rather than a type of them. Revising by defining property rather than by example is what separates the two quickly.

No directly related past PYQ was found.

• practice — not a real PYQ

  Which one of the following is the best example of a hard real-time application?

  • (a)Playback of a streamed video
  • (b)An anti-lock braking system in a car
  • (c)A monthly payroll run
  • (d)A word processor's spelling checker

  Answer(b) An anti-lock braking system in a car — the controller must act within a deadline measured in milliseconds, and a late response is a failure with physical consequences, which is the definition of hard real-time. Streamed video is soft real-time, since lateness only degrades quality, while a payroll run is a batch job and a spelling checker has no deadline at all.

• practice — not a real PYQ

  Which scheduling approach is characteristic of a real-time operating system?

  • (a)First come, first served
  • (b)Round robin with equal time slices
  • (c)Priority-based pre-emptive scheduling
  • (d)Shortest job first, without pre-emption

  Answer(c) Priority-based pre-emptive scheduling — the most urgent ready task must be able to take the processor away from a less urgent one immediately, which is the only way a deadline can be honoured in the worst case. Round robin is built for fairness among interactive users, and the two non-pre-emptive schemes let a running task hold the processor while a deadline passes.