Operating systems: sharing resources without mixing tasks

By UK GCSE Computer Science · independent study · myAudience

Original AI-generated teaching illustration via built-in image_gen; author inspected 2026-10-04. · Generated project artwork; no copied exam/publisher figure. Independent publication review pending.

Operating systems: sharing resources without mixing tasks

Application software serves an end-user task, such as editing a document; system software helps provide and manage the environment in which applications operate. An operating system manages resources including processor time, memory, I/O devices, application execution and security. Utilities perform support or maintenance functions such as backup or file checking. These classifications describe functions rather than whether software is visible on screen. A system tool can have a user interface, and a library or service can support applications without itself being the user's main task.

Processor management is different from instruction decoding. The CPU follows instruction mechanisms; the OS decides which runnable task should receive processor time according to its scheduling policy. In a simplified one-core timeslice model, A and B take turns, creating responsive interleaving rather than literally executing at the same instant. On multiple cores some work can execute simultaneously. The distinction prevents the claim that the control unit chooses the user's next application or that an OS performs each arithmetic instruction itself.

Memory management tracks and provides working memory for programs, with mechanisms that can help keep one process's state separate from another. Real systems can use virtual address spaces and protection; the precise page-table machinery is optional beyond this GCSE slice. Two applications both referring to a local address do not necessarily mean they share the same physical data. Allocation and protection explain why an application should not overwrite another's working state merely because both are running. A deliberately shared resource needs an explicit arrangement, not accidental address confusion.

I/O management provides controlled interaction with devices, often through device drivers and system interfaces. An application requests a print or file operation; it need not contain every physical device detail. A queue can coordinate requests and report errors rather than treating a delay as immediate failure. Application management supports starting, running and ending programs. These roles connect: a task waiting for a device may allow another task to use a core. The plate distinguishes these responsibilities without asserting that all real implementations fit five isolated boxes.

Security management includes checking identities and permissions for resources. Permission to open a file does not itself mean its contents are encrypted, and encryption does not by itself grant a user permission. A protected OS interface can refuse an operation when the caller lacks authority. Running multiple programs creates reasons for boundaries and controlled access, not a guarantee against every vulnerability. This is conceptual access-control teaching, not instructions for bypassing a real system. The correct evaluation identifies what protection is claimed and what remains outside it.

A fictional scheduler gives A and B alternating2ms slots on one core, with no switching cost. A needs4ms total CPU work and B needs6ms; both are ready at time0. Slots0–2A,2–4B,4–6A complete A at6ms. Then6–8B and8–10B complete B at10ms because no A work remains. Total CPU work is10ms, but A's completion time is6ms, not its4ms service demand. This separates response/completion experience from processor occupancy. Real waiting, priority and switching costs are excluded; no production OS scheduling claim is made.

Change the model to include0.5ms overhead each time switching between different tasks, with no initial or final overhead. A0–2, overhead2–2.5, B2.5–4.5, overhead4.5–5, A5–7 complete A at7. Overhead7–7.5, B7.5–9.5 then B9.5–11.5 complete B at11.5. There are three changes, not four, because consecutive B slots do not change tasks. The unchanged10ms service plus1.5ms overhead explains total11.5. This is a worked example of resource management with transparent assumptions rather than an advertisement for a scheduling policy.

Transfer: a user says two applications taking turns proves the CPU physically has two cores, and allowing a program to read a file proves the file is encrypted. Both inferences fail. Interleaving is possible on one core; simultaneous independent execution would require different evidence. Permissions govern access, whereas encryption concerns data representation and keys. A full answer states the relevant distinction, offers a counterexample consistent with the observation and explains what extra information would settle the question. This form of justification connects OS mechanisms to evidence instead of collecting vocabulary alone.

Worked example: Trace the stated zero-overhead one-core schedule and distinguish demand from completion time.

A executes0–2ms and4–6ms:4ms work, finishes6ms.

B executes2–4,6–8,8–10ms:6ms work, finishes10ms.

No remaining A work means no artificial idle A slot.

Answer: A finishes6ms, B10ms; CPU demand totals10ms, even though A waits between its slots.

Check your understanding: Add0.5ms for each change between different tasks, excluding initial/final overhead. Calculate completion times and justify the change count.

Answer: A runs0–2 and5–7ms, finishing7ms. B runs2.5–4.5 and7.5–11.5ms, finishing11.5ms. Three switches A→B,B→A,A→B add1.5ms; continuing B at9.5ms is not a switch. Total10+1.5=11.5ms.

Why: The answer tracks actual transitions and retained work rather than charging a switch for every slot or confusing CPU service with elapsed completion.