Introduction to Operating Systems

Introduction to Operating Systems

1.1 Course Structure: Modules, Assessment, and Resources

1.1.1 The Roadmap: What the Course Covers

This opening session is the first module of the course, and it is an introduction: what an operating system is, the definitions people give for it, how a computing system is put together, the design issues that come up, and the different types of systems that exist. Everything that follows is set up from here.

Module one covers this introduction. From the second module onward, the course moves into processors and threads, and then into how processes get scheduled, what the different scheduling algorithms are, and what process synchronization means. The professor flagged these as very important topics. After that come process synchronization and deadlock: what a deadlock is, how to prevent it, how to avoid it, and how detection and recovery work. Then memory management — if you have very little memory, how do you manage with many processes? Then file systems — how the operating system deals with files — and finally secondary storage structures and management, meaning the different scheduling algorithms that exist for the disk. With that, the course completes.

Everything discussed in the course is about the general characteristics of operating systems, not about any one particular operating system. Wherever a concept applies to a specific system, that example is quoted at that point in the course.

1.1.2 Assessment Breakdown

The evaluation has three components, and it is worth writing them down once so the numbers stay straight for the whole semester:

Everything is conducted online — if a component is a lab, it is conducted as an assignment: you simulate the given exercises in the CPU-OS simulator, take snapshots of the output, and submit them by the announced date and time. If any change is announced, it will be put on the portal. Dates were announced as fixed: the mid-semester on March 16 and the comprehensive exam on Saturday, May 18.

1.1.3 Textbooks and References

The standard textbook for the course is Operating System Concepts by Abraham Silberschatz, and the e-book is available on the e-learning portal — the professor pointed out that it is readily available there. The PowerPoint-style session materials follow this textbook closely. For reference, two more books were named: William Stallings, Operating Systems: Internals and Design Principles, and The Design of the UNIX Operating System, which the professor noted is relevant to a topic that appears in the second or third unit of the syllabus.

For the assignment, you will download the CPU-OS simulator from the course site, and a demo will be given before the mid-semester, because the assignment is to be submitted after the mid-semester. The list of exercises can be done individually or in a group; groups are limited to four members.

1.1.4 How the Class Runs

This session runs for one and a half hours, and the course follows a flipped mode. Recorded sessions are available on the portal, and you are expected to go through them before coming to the contact session. Session materials are posted on the same day the session completes. Announcements for every quiz and assignment are made well in advance on the portal. There are eight contact sessions covering the mid-semester portion. If something cannot be completed in a particular session, it simply moves to the next session.

1.1.5 Opening Exchange: Any Doubts?

1.2 What Is an Operating System?

1.2.1 The OS as a Program That Bridges User and Hardware

An operating system — the program that sits between you and the machine — is first of all a program: a set of instructions that performs some task. What makes it special is its position. The operating system acts as an intermediary, an interface, or a bridge between a user and the system, where "system" means the hardware sitting in front of you. Most people use a laptop or desktop every day, but in detail, what the operating system does internally — that is what this course opens up.

Through this bridge the user can execute whatever programs they want, make problems easier to solve, and make the system easier to use — and, importantly, the operating system also does these things efficiently. Those are the various goals of the operating system; more of them appear later in the course. Where does the analogy hold, and where does it break? A human translator changes the words but not the meaning; the operating system is stricter — it does not merely translate, it decides whether a request is allowed at all. A user program cannot quietly ask the disk to overwrite another program's file; the operating system checks the request first. That checking role appears again in the dual-mode discussion later in this lecture.

1.2.2 The Four Components of a Computer System

The overall structure of a computing system has four components, and they are worth holding in your head for the whole course:

1. Hardware — all the devices: memory, CPU, and everything else physically present.
2. The operating system — the component that controls and coordinates the use of the hardware among various applications and among the users.
3. Application programs — the software that runs on top of the operating system, each with its own purpose.
4. Users — the people (or other systems) who use the machine.

Imagine a network of systems: each system is used by a user, in an organization, an institution, or a lab. The same system can also be used by multiple users, and multiple programs or tasks can run in parallel on one system. A user can be a human being, or it can be another system — a server sitting somewhere else, or another machine in the same local network. When you interact with that other machine, you are the user and it is another "user" in the network from the operating system's point of view.

Application programs are built for a specific purpose. A text editor, where you type text and make changes, is one. Word, PowerPoint, and Excel are application software. Games are application software. A browser is application software too: through it you interact with your own system or with a remote one — when you search and click a link, the information travels from a place that is not near you, and it is the operating system, together with the hardware, that reaches out to the remote server and brings the information back to your screen. Whenever any software has to deal with hardware, the operating system is needed.

Real-world: that last sentence is the hidden cost of every web search. The bytes of your query leave through a network card, travel to a distant server, and return — and the operating system arranged every step of that journey, from opening the network connection to writing the reply onto your screen.

1.2.3 Goals: Easier to Use, Efficient to Run

The operating system exists for convenience and for performance. Resource utilization — making sure the CPU, memory, and devices are put to good use — is very important, but as a user you do not think about it. You do not decide how memory is managed or how resources are shared; the operating system does. The system tries to keep resource utilization high while keeping the system usable. Later sections show exactly how it goes about that.

1.2.4 Kinds of Computer Systems

Many kinds of computer systems exist, and the operating system adapts to each:

• Desktops — the classic personal machine.
• Workstations — in a network of systems, each user is given a workstation.
• Handheld computers — from mobiles to iPads. Handheld systems are the interesting case: the resource utilization may be poor — you may not be using all the resources — but the system is optimized for usability. You use it until the life of the battery runs out; that is the trade-off the design makes.
• Embedded systems without any interface — used in automobiles and other smart devices. A car may have components installed (a music system, sensors) that you do not use all the time; you use them when you take the car out. A sensor does its work only when someone comes or something happens, and otherwise sits idle. Even a CCTV that monitors a house all day is idle most of the time you look at it. These systems are utilized rarely, and the operating system still has to manage that sporadic usage.

1.2.5 Industry Applications: The Operating System Landscape

Most people meet operating systems as products. Microsoft Windows is the most widely used, holding about 64% of the usage of today's systems; Unix or Linux comes next, then the Mac (macOS). On mobile devices, Android and iOS dominate. Solaris, part of Sun Microsystems, also exists.

Historically, the first operating system was developed for IBM hardware by General Motors — GM-OS was the first system that was developed, and all later systems followed from that start. The reference literature agrees: the first batch operating system, and the first operating system of any kind, was built in the mid-1950s by General Motors for the IBM 701, and the idea was then refined on the IBM 704 before spreading to commercial machines. So "GM-OS" is the correct name to hold onto.

Unix is written in the C programming language — a high-level language — and was developed by Ken Thompson and Dennis Ritchie working together. The course mostly studies Microsoft, Unix or Linux because those are the widely used systems.

1.3 The Operating System as Resource Allocator and Control Program

1.3.1 The Resource Allocator View

The classic definition of the operating system: it is a resource allocator — the one program that manages all the resources of the system. Many resources exist. The operating system decides which process gets the processor. Main memory is limited, so not every process can live there at once; most processes wait in secondary storage. Secondary storage means magnetic tape, magnetic disc, and optical discs — CDs, DVDs, and Blu-ray discs are examples of optical discs — and now SSDs, solid-state drives, which are based on solid-state devices, faster than hard disks but very expensive; even a small SSD costs more.

The scarce-resource picture shows why allocation is needed at all. Consider a machine with 8 GB of main memory and twenty running processes whose combined needs are 30 GB: fourteen gigabytes of demand simply cannot fit. The operating system must choose which processes live in memory, which wait in secondary storage, and how the 8 GB is divided. Every memory card, every disk drive, and every CPU cycle is the same story: demand exceeds supply, so someone has to ration.

1.3.2 The Control Program View

A second classic definition: the operating system is a control program — it controls the execution of various programs. The system programs it controls include compilers and assemblers. A compiler translates high-level language programs into machine-level language. An assembler translates low-level assembly-language programs into machine-level language. Controlling the execution of these programs — every time you switch on the machine — belongs to the operating system. If the operating system stops working, or something happens to it, the whole system crashes; that is how central it is.

Real-world: a compiler is itself a program — the C compiler that built the browser you use today was itself run under the control of an operating system. So the control program supervises the tools that make other programs, and a failure anywhere in that chain takes the whole machine down.

1.3.3 The Bootstrap Program and the Kernel

When you switch the system on, power it up, or reboot, the first program to run is the bootstrap program — the term that came through garbled in the session ("gini process") is the standard one: the bootstrap program, also called the boot loader, the first program that runs when the system boots. The bootstrap program is stored in read-only memory (ROM) or in an electrically programmable read-only memory (EPROM), which is also called firmware. (Textbooks often write the second option as EEPROM — electrically erasable programmable read-only memory — the difference is only in how the chip is reprogrammed; the role is the same.) It initializes all the configurations needed for the system to start execution. This is the first program that runs in your system, and everything else is controlled by the operating system from that point on.

At the heart of it all is the kernel. The kernel is the program that runs every time on the system — the one that is always there — and it is the core of the operating system. With the help of the kernel, programs interact with the hardware: any program that needs hardware goes through the kernel. You can think of the kernel as the permanent resident of the system, the part of the operating system that never leaves memory while the machine is on.

1.3.4 No Single Definition

The session made the point that there is no single definition of an operating system. Each person — each textbook — offers one: resource allocator, control program, the program that runs every time. From all of these together you should be able to say what the operating system is.

1.4 Computer System Operation: Controllers and the Bus

1.4.1 Devices and Their Controllers

A computer system has a CPU and various controllers, and each controller is responsible for interacting with a particular device. The disk is secondary storage, and interacting with it — reading information or writing information — is controlled by the disk controller. The mouse, keyboard, and printer are input-output devices, and the information that passes through them is handled by the USB controller. To display information on the monitor you need the graphics adapter. Every device of this kind has its own controller that speaks to the rest of the system on its behalf.

Why this layering matters: the disk, the keyboard, and the display speak completely different languages. The disk speaks in tracks and sectors, the keyboard in scan codes, the display in pixel coordinates. If the CPU had to speak all of these directly, every new device would force a redesign of the processor. Instead, each device is represented by its own controller, and the CPU talks to controllers — the device's details stay inside the controller. The operating system later exploits the same idea at the software level with device drivers, which are introduced in the caching section.

1.4.2 The Common Bus and Memory Cycles

All of these controllers need a common thing to share information: the bus. Through the bus, information is shared among the devices, and memory is accessed by all of them. The CPU and many devices execute concurrently, which means two or more processes may be competing for the same device at the same time; the memory cycle gets utilized by more than one program or process at once. That competition for memory cycles is exactly the kind of problem the operating system later has to sort out.

A modern general-purpose computer system so looks like this: one or more CPUs and a number of device controllers, all connected through a common bus that provides access to shared memory. The CPU and the device controllers can execute concurrently — the disk controller can be moving data while the CPU computes — but when they compete for the same memory cycle, the system needs an orderly way to share it. The memory controller exists precisely to synchronize access to the shared memory. That arbitration is a hardware problem today; later in the course the same competition reappears as a software problem, when the operating system must schedule processes that fight over the CPU and the I/O devices.

1.5 Interrupts: How the OS Finds Out What Happened

1.5.1 What an Interrupt Is and How the Vector Works

A device controller does its work and then has to tell the CPU that the operation has completed. It does this with an interrupt — it interrupts the execution of the processes running on the CPU by informing the system that this particular thing has been completed. You already use interrupts: Ctrl+C means stop, Ctrl+Z and Ctrl+A are interrupts as well, and each one does its own job.

Think of the interrupt vector as a directory: it is a table of pointers to interrupt routines, stored in low memory, and each device is given a number that indexes into the table. When the disk controller raises an interrupt with device number 14, the CPU looks up entry 14 in the vector, finds the address of the disk's service routine, and jumps there. No searching, no guessing — the address comes straight from the table, which is exactly why interrupt handling can be fast enough to keep up with devices.

1.5.2 Hardware and Software Interrupts, Traps and Exceptions

Interrupts come in two kinds. A hardware interrupt is generated by one of the devices connected to the system — Ctrl+C and similar are hardware interrupts. A software interrupt is based on a user request or on an error caused by a program: when a program does something wrong, it causes an exception, and the exception makes a trap — a software-generated interrupt. If a program runs into an infinite loop, that is also the kind of event that produces a software interrupt.

The key takeaway: the operating system is interrupt driven — it works based on the interrupts it is given, whatever they are.

1.5.3 Handling Interrupts: Polling vs. Vectored Interrupts

Once an interrupt occurs, it has to be handled. Handling can be done in different ways: with the polling method, or with a vectored interrupt system. These methods identify what type of interrupt has happened, and the appropriate service routine is activated. The vectored approach uses the interrupt vector's addresses; polling checks the devices in turn to see who is requesting service.

When to pick which: polling is fine when devices are few and interrupts rare; once many devices share the system, vectored interrupts win because the device number leads the CPU straight to the right routine.

1.5.4 The Interrupt Timeline: Keeping CPU and I/O Busy

The session walked through the timeline of interrupts as a diagram. There is a line for the user process executing on the CPU and a line for the I/O device. When the I/O device is idle, its line is flat; when it does some work, the line is triggered — an edge — and then it goes back up when the device goes idle again. When the user process is executing on the CPU, its line is up at a level; when it is not doing work, the line is down. The two lines move in opposite directions: when an I/O request comes for a process, the process stops its execution, the CPU line drops, and the I/O device does its work; once the transfer completes, the I/O device goes idle again and the CPU starts executing the next user process. This constant alternation between CPU and I/O is what the diagram shows.

Sense-check: the diagram shows the entire trick of modern systems in two lines — the CPU never stands idle while I/O runs, and the I/O device never stands idle while the CPU runs. When both lines are busy for most of the timeline, utilization is high.

Two failure modes show up on the same diagram. If more processes try to execute on the CPU than it can handle — when the CPU has a queue that is too long — the I/O device sits idle the whole time. If the I/O device has a full queue of processes, the CPU sits idle. In both cases, utilization of the devices is very low; it is either the CPU or the I/O that starves.

The important design rule that follows: as soon as the I/O starts, control returns to the user program without waiting for the I/O completion. Once a process has started its I/O, the next process in the queue gets the CPU — the CPU should not be idle. When that next process later finishes its turn or goes to I/O, it returns to the ready queue and waits for its turn again. There should always be some queue of processes, either at the CPU or at the I/O, to get full utilization of both. That is very important.

1.6 System Calls and the Device Status Table

1.6.1 System Calls as Requests to the Operating System

How does a process actually get moved to the CPU or to the I/O? Through a system call: a request we make to the operating system that allows the user to go for I/O or to go for CPU execution. Which of the two you get depends on what type of system call you use. System calls are the standard way a user program asks the operating system for something it is not allowed to do directly.

The "depends on what type of system call you use" point matters: system calls are not one thing but a family. A read system call moves the program to the I/O side (it will wait while data is fetched); a request for CPU time moves the program into the ready queue. Later in the course, the type of system call becomes part of how the operating system decides what happens next to a process.

1.6.2 The Device Status Table

To manage all devices, the operating system keeps a device status table: an entry for each and every device, recording what type it is, what its address is, and what state the device is in — whether it is running, ready, or terminated. Every time the situation changes, the values in the table change and the operating system has to modify the table accordingly. That table is one of the ordinary pieces of bookkeeping the operating system does all day.

Sense-check: three fields, one row per device, and the state column is the volatile one — that is where most of the changes land.

1.7 Storage Structure: Units and the Device Hierarchy

1.7.1 Bits, Bytes, and Words

Before the storage structure, the basic units of storage. A bit is the basic unit of storage: either 0 or 1. A byte is a combination of 8 bits, and it is the smallest chunk of storage — a byte is very, very little. Some systems also talk in terms of a word, which depends on the architecture: a word can hold more than one byte, up to 4 bytes or up to 8 bytes. On a 64-bit memory-address system the words are 64-bit words, which means 8 bytes. When the system executes an operation, the block of storage it works with is called a word rather than a byte. Above these, the measurements are the familiar kilobyte, megabyte, gigabyte, terabyte, and petabyte.

A worked number to fix the scale: a 64-bit machine reads a word of $8\text{bytes}=64\text{bits}$ at a time; a 32-bit machine reads $4\text{bytes}=32\text{bits}$. Same instruction, different chunk size — which is why the same program runs at different speeds and memory footprints on the two architectures.

1.7.2 The Storage Hierarchy and What the Arrows Mean

The device hierarchy runs: registers, cache, main memory, solid-state drive, hard disk, optical disk, and magnetic tapes. The diagram carries two arrows. The down arrow tells you how big the storage device is — capacity grows as you go down the hierarchy. The top arrow tells you how fast information gets retrieved from the device — speed grows as you go up. Registers are very, very fast but very limited; a particular processor may have only eight registers or twelve, and the information you store there is tiny. The cache is a very, very small memory, an intermediate memory, and the often-used information is placed there — with the cache, execution becomes much faster, but you cannot place more than a small amount in it. Main memory is bigger than the cache, and the CPU can access it directly. SSD is faster, and again the amount of storage is not large because it is very expensive. The hard disk is bigger in size and not very expensive when compared with the SSD. Optical disks are very, very inexpensive. Magnetic tapes are not at all expensive but are not used much nowadays.

Visualize the hierarchy as a pyramid. The apex is registers: a handful of words, accessible in one clock cycle. Below them the cache: kilobytes to a few megabytes, nearly as fast. Below that main memory: gigabytes, directly accessible by the CPU. Then the SSD (tens to hundreds of gigabytes, much slower than RAM), then the hard disk (terabytes, slower still), then optical discs, and at the base magnetic tapes — enormous capacity, tiny cost, and retrieval times measured in seconds, which is why tapes survive only for archival backups. The two arrows are the pyramid's two faces: speed on the way up, capacity on the way down.

1.7.3 Volatile vs. Non-volatile Memory; Inside the Hard Disk

Two properties of memory matter for everything that follows. Main memory is volatile: the information stored in it vanishes as soon as you switch the system off. Secondary storage is an extension of the main memory and is non-volatile: even when you leave the system, the information you stored is still there.

Inside the hard disk: it is a metal covered with a magnetic recording material. The disk surface is divided into many concentric circles called tracks, and each track is divided into many sectors. The disk controller provides the interaction between this device and the system.

Visualize the platter as a vinyl record: the grooves are the concentric tracks, and each groove is chopped into arcs — the sectors. To read one piece of data, the head must reach the right track (a slow mechanical motion) and then wait for the right sector to rotate under it. Those two mechanical delays, seek time and rotation time, are the reason a disk is thousands of times slower than memory — and the reason the operating system cares about disk scheduling later in the course.

1.7.4 How the Levels Sit: Speed, Cost, and Capacity

The storage system is always organized in terms of speed, cost, and capacity. Solid-state drives are common in today's systems — the operating system itself is stored on the SSD and the system boots from there — but because SSDs are very expensive, capacity stays small. Previously flash memory was used; nowadays everything has come into SSD. Optical discs (CD, DVD, Blu-ray) are nearly free. Magnetic tapes are cheap but rarely used now. The course deals mainly with main memory, magnetic disks, and solid-state drives; registers and cache are studied in the computer organization and architecture courses.

1.8 Caching and Data Migration

1.8.1 Caching: Main Memory as a Cache for Secondary Storage

Caching is the name for putting the information you will need soon into faster storage. The cache holds the recently and often-used values. The picture extends across the whole hierarchy: main memory can be viewed as a cache for the secondary storage — main memory is bigger than the cache, but it is still small compared with the disk, so it holds the working set of what is needed right now. Each device has its own device controller and device driver to manage its I/O operation. Many levels of caching exist, studied in detail in computer organization and architecture; for this course, the key idea is that faster storage holds less information.

The everyday picture is a desk and a filing cabinet. The cabinet holds everything (the disk); the desk drawer holds what you use today (main memory); the top of the desk holds the sheet you are working on right now (the cache). The relationship repeats at every level of the hierarchy: main memory is a cache for the disk, the cache is a cache for main memory, and registers are a cache for everything below. The rule that ties it all together: faster storage holds less information.

Where does the analogy break? A desk drawer must be emptied and refilled by you; the cache is managed automatically — you never choose what goes in it. What is in the cache is decided by what the program actually touched, most recently and most often.

1.8.2 Data Migration: From Disk to Register

When information lives on the hard disk, it does not jump straight to the CPU. The path: move the information from the disk to main memory first; from main memory it goes to the cache; and finally, if necessary and safe, it reaches a register. Registers hold very small data, so small data can be placed in a register, but large data cannot — large data stops at the cache level. The cache does not hold everything either, only the most recently used values. And main memory cannot keep every program; whatever is necessary is brought into main memory, and whatever is not necessary is put back into the disk. That is how the migration of information from the disk to the register takes place.

Sense-check: every trip upward gets faster and carries less, and every value that is no longer needed travels back down again. The phrase "if necessary and safe" in the register step means: only small data (a word or two) goes all the way up, and only data whose change is allowed to be visible goes down again.

1.8.3 Who Manages Each Level

Each level has a different manager: registers are managed by the compiler; the cache is managed by the hardware; main memory, solid-state drives, and magnetic disks are managed by the operating system. The course does not deal with registers and cache; the parts to know are main memory, magnetic disk, and solid-state disk and who manages them.

1.9 Memory Access: von Neumann and Harvard Architectures

1.9.1 von Neumann: One Shared Bus

In the von Neumann architecture, there is a common bus that moves data between memory and the CPU. The CPU has the cache on one side and the threads of execution on the other. When the CPU makes an I/O request, it has to go to the particular device, and data is shared between them; if an interrupt occurs in that device, the interrupt is informed to the CPU, and the execution of the particular thread or process stops. Memory holds both the instructions and the data: the instruction has to move to the instruction register, and the data has to move to the registers used for data movement. All of this happens over the common bus, and that single bus is what limits the time taken to move information.

1.9.2 Harvard: Separate Buses for Data and Instructions

The Harvard architecture is the other type — a hardware architecture with separate buses for the data and for the instructions. Because the two kinds of traffic no longer share one bus, the speed increases. That is the whole point of the distinction: von Neumann shares one path, Harvard gives each direction its own path.

When to pick which: general-purpose systems accept the shared bus for simplicity; embedded processors that must react in real time take Harvard's extra speed, at the cost of more hardware.

1.10 Multiprocessor Systems

1.10.1 Multiprocessor vs. Multiprocessing

Any system architecture in general uses a single general-purpose processor, and some systems may also have special-purpose processors. Nowadays, though, most systems are multiprocessor-based: multiple processors present in a single system.

The professor's correction is worth keeping straight: multiprocessing is the verb (many tasks in progress), multiprocessor is the noun (a machine with several processors). The same distinction reappears everywhere in this course — between what a system does and what it is.

1.10.2 Why Go Multiprocessor: Throughput, Economy of Scale, Reliability

Three reasons were given for building multiprocessor systems. First, throughput: the number of works completed with respect to the total number of processes. With multiple processors, more processes get completed in the same time. Second, economy of scale: at a time you can execute more than one, so your time is saved. Third, increased reliability: you can rely on the system even if one processor fails, because two or three more are still there. Related to reliability is graceful degradation: the degradation will not be abrupt — the system slowly degrades, so you get to know about it and can change it out. That combination is called fault tolerance.

1.10.3 Asymmetric vs. Symmetric Multiprocessing

There are two types of multiprocessor systems. In asymmetric multiprocessing, each processor is assigned a task: the first processor does one work, the second processor does another. In symmetric multiprocessing, each processor performs all the tasks. Suppose there are four tasks: the four tasks are divided among each and every processor, and all four processors work on them together — each processor does its component of the task in parallel, and the results are sent to the memory later. In the symmetric multiprocessing architecture, each processor has its own CPU, its own registers, and its own cache.

Sense-check: asymmetric = "each processor owns its job"; symmetric = "all processors share all jobs". SMP wastes less hardware but needs more coordination — every processor's results must be merged in memory, and the operating system must be written to run on several processors at once.

1.10.4 Multi-core and Multi-chip Designs

Take a chip, and inside that chip you can have multiple processors or cores. A dual-core component has two cores; a quad-core component has four. Each core has its own register and its own cache. Designs can be multi-core and also multi-chip. Companies differ: some processors go up to 128 cores, some have 54, and the common counts are 2, 4, 6, 8, 16 — it depends on the company and the processor you choose. Intel, ARM, and AMD each design their own cores.

Real-world: a modern phone and a modern laptop both run on multi-core chips — a four-core or eight-core part — which is why you can have a browser, a game, and a document editor making progress at the same time.

1.11 Cluster Systems

1.11.1 Clusters and the Storage Area Network

A cluster system is another type of system, like multiprocessing: here also multiple tasks are performed, and the work is done using a storage area network (SAN). The storage is shared among the various systems by using the SAN, and many systems are interconnected to each other and to the SAN.

Why not just one big multiprocessor? A cluster of ordinary machines is often cheaper to buy and to expand than one enormous custom-built computer, and — as the next subsection shows — it keeps working even when a whole machine dies.

1.11.2 Higher Availability and Two Flavours of Clustering

The main advantage of a cluster is higher availability. Even if one system fails, the next system takes the information and does the work, or the work is shared among the rest of the systems. There are two kinds of clustering. In asymmetric clustering, one machine is always in the SAN as standby: if one of the machines present in the cluster fails, that standby machine becomes the backup for it. In symmetric clustering, each and every system runs in parallel and each monitors the others; more than one node runs the applications. All of this is done mainly for parallelization — and to keep the whole set of systems working properly.

Sense-check: one machine stands by in the SAN; when a working machine fails, the standby becomes the backup — the whole point of the cluster is that a single machine's death is a non-event.

The alternative, symmetric clustering: every machine runs applications and monitors every other. If one node fails, its load simply redistributes among the rest — no idle standby needed, but every node must be able to take over every other's work, which requires more careful coordination.

1.11.3 The Distributed Lock Manager

With many systems sharing storage, there is always the danger that the same operation accesses the same variable at the same time. That conflicting-operation problem is taken care of by the distributed lock manager (DLM): it coordinates locks so that conflicting operations do not collide on shared data.

1.12 Multiprogramming and Time-Sharing Systems

1.12.1 Multiprogramming (Batch) Systems

Multiprogramming is a type of system that organizes jobs so that the CPU always has some program to execute. Always some set of jobs will be in memory to be executed, from which one job is selected for execution. When one job goes for I/O, the next job comes for execution — and the rule to remember: the CPU and the I/O should always be kept busy; they should never go idle. This is the batch type of system. In the memory layout for a multiprogramming system, multiple jobs sit in memory, and each job is taken for execution; which job runs next depends on the queue in which the jobs arrive at that moment.

Sense-check: multiple jobs sit in memory, one is selected for execution, and when it requests I/O the next job runs — the queue decides who is next.

1.12.2 Time-Sharing (Multitasking) Systems

The next type is the time-sharing system, also called multitasking. Here the CPU switches between jobs after a particular time slot: a response time is given, after which the processes switch to the next job and it starts executing. So multiprogramming switches when a job blocks on I/O, while time-sharing switches on a timer, so that every user's job gets its share of the CPU in turn.

When to pick which: batch multiprogramming suits long, non-interactive workloads; time-sharing suits classrooms, offices, and any place where people type and expect an answer.

1.13 Dual-Mode Operation: User Mode and Kernel Mode

1.13.1 User Mode and Kernel Mode

Dual-mode operation is very important: it is the mechanism that helps the operating system protect itself and the other components of the system. There are two modes. In user mode, the user has certain privileges and can run only those programs, processes, or jobs that those privileges allow. In kernel mode, the user does not have those privileges; the kernel has the privilege to operate in both the user mode and the kernel mode. Not everyone can execute privileged instructions — those run only in kernel mode. The mode is distinguished with the help of a bit provided by the hardware, the mode bit.

1.13.2 The Mode Bit and a Notation Confusion

1.13.3 System Calls as the Gateway to Kernel Mode

When a system call occurs, the system switches from user mode to kernel mode. System calls include read — if you have to read information — and write — if you have to write information — plus opening a file and closing a file. If you are executing in user mode and make one of these calls, the system switches to kernel mode; only after going to kernel mode does the system call work. Once the read or write completes, the system returns from kernel mode to user mode and the user process continues.

The transition works like this: the user process is executing; when a system call comes, a trap occurs; the mode bit is set to zero and the system call is executed; after the system call completes, the mode bit is set to one and control returns to the user process.

1.13.4 The Timer and Infinite Loops

Along with the mode bit there is a counter, or timer, which is set before execution. The counter gets decremented, and when the counter becomes zero, an interrupt is generated; the interrupt is handled, and the process continues from user mode. The point of the timer: it must not be allowed to run into the infinite — the system has to take care of that. Because the timer fires an interrupt at zero, no single process can hold the CPU forever in an infinite loop; it gets cut off when the timer expires. This is how a software interrupt from an infinite loop gets caught.

A concrete scale: a 10-bit counter with a 1-millisecond clock allows interrupt intervals from 1 millisecond up to 1024 milliseconds ($2^{10}=1024$), in steps of 1 millisecond. A program with a 7-minute time limit has its counter set to 420 seconds' worth of ticks — and when the count reaches zero, the timer interrupts and the operating system regains control. The instructions that modify the timer are privileged, so a user program cannot quietly disarm its own safety net.

1.14 Process Management

1.14.1 Process vs. Program: Passive and Active

A process is any program in execution; you can also call it the unit of work performed by the program.

The session used an arithmetic program as the example: even a small program may have functions — one that makes a sum, one that makes a difference, one that does multiplication, one that does division — and each function can be imagined as a separate module, a separate process, each of which may be in execution at a given moment.

Sense-check: one passive file, four active executions — the sum process finished at 8 while the multiplication process was still computing 42.

1.14.2 Resources a Process Needs, and the Program Counter

If a process has to work, to accomplish its task, it needs resources: a CPU, memory, the I/O, a file, and, apart from that, some other data. All of this information is required to complete the particular task. When the process completes its execution, it returns whatever memory, I/O, or CPU it utilized. There will always be a program counter (PC) for a single-threaded process: the PC holds the address of the next instruction to be executed — the same program counter you met in computer organization. If the process is multi-threaded — many threads per process — then each thread will have its own program counter.

1.14.3 Many Processes, Many Threads in a Running System

Any real system runs multiple processes concurrently. Real-world: with VMware you can put another operating system on top of a Microsoft operating system, and there a separate operating system runs as a program — so you can have one or more CPUs running in parallel, executing many processes or threads concurrently. On a desktop, you may have a Word file open, a browser open, a gaming application open, and some other software — all running in parallel; a single user can execute many programs at a time. Inside one process, threads multiply: in Word, at the same time you may be typing and the spelling checker may be checking — many threads work on your behalf within that one application.

Sense-check: a browser and a game are separate processes competing for the CPU; typing and spell-checking are threads cooperating inside one process — they share Word's memory and files, which is exactly why threads are cheaper than processes to run.

1.14.4 What the Operating System Does: Create, Delete, Suspend, Resume

With all these activities, the operating system is responsible for process management: creating and deleting both user and system processes; suspending a process; resuming a process; and providing mechanisms for synchronization, communication, and deadlock handling.

1.14.5 Deadlock: When Processes Wait on Each Other

What is a deadlock? When too many processes try to access the same resource, and no process can use the resource effectively, there comes the deadlock: each process may be waiting for the other.

Sense-check: when the wait is real — P1 and P2 cannot proceed and P3 cannot finish without something they hold — the resource sits idle and the processes wait on each other: that is the deadlock.

How to handle a deadlock: some mechanisms exist, and the course covers prevention, avoidance, and detection and recovery — all done by the operating system.

1.15 Memory Management

1.15.1 Bringing Programs into Memory

Whatever instructions a program has must be executed from memory, so the program first has to be brought into the memory. The program may be sitting somewhere on the disk; the operating system has to get it from there into main memory before any of its instructions run.

1.15.2 Tracking, Allocating, Deallocating

Memory management is a set of tracking duties. The operating system keeps track of which parts of the program are there in the memory, which parts have been used, and who is going to use them. If a part is not necessary, the operating system decides whether it should be moved into the secondary storage. If memory is allocated to a particular process but the process is not using it at all, the operating system has to deallocate the memory. All of this — allocation, tracking, swapping out, deallocation — is handled by the operating system.

1.16 Storage Management and the I/O Subsystem

1.16.1 Files as the Logical Storage Unit

Storage management works in terms of a logical storage unit called a file — everything should be organized as a file. A file is a collection of information. The operating system's file activities: create and delete files, manipulate files, map the files to the secondary storage device, and bring files back from secondary storage into the main memory.

The professor's rule — everything should be organized as a file — is more than habit: devices, program data, and documents are all exposed through the same file interface, which is why one set of file operations (create, delete, manipulate, map to storage, bring back to memory) covers the whole machine.

1.16.2 Mass Storage Management

Main memory cannot hold all the information, so information that is not necessary at that point of time is taken into the secondary storage device. The operating system's mass-storage activities are free space management, storage allocation, and scheduling. Some storage need not be very fast, but it still has to be managed by the operating system or by the application that uses it.

1.16.3 The I/O Subsystem: Buffering, Caching, Spooling

The I/O subsystem is responsible for buffering, caching, and spooling — the three techniques that smooth out the speed difference between the CPU and the slow devices around it.

The three techniques share one purpose: they absorb the mismatch between the machine's fast inside and slow outside. The CPU writes at memory speed, the printer takes seconds per page — buffering, caching, and spooling build bridges of waiting data between the two speeds.

1.17 Protection and Security

1.17.1 Why Protection Matters

Protection and security are very important. A resource cannot be used by all the users at all the times; it should be protected, and high security should be there against external or internal attacks. The attacks can be any type: a denial-of-service attack, a virus, or any type of theft — the operating system should be secured against them.

1.17.2 User IDs, Group IDs, and Access Control

Security starts with identity: we should know who all the users are going to use our system, and the identity of the user is very important. Each user ID is associated with a particular file or a process, and it is associated with a group as well: if there is a group ID, the group has these many users. Each group is given a particular privilege, so the group can use certain processes or certain information or files. This kind of access control should be provided — and that rounds out the introduction. The next sessions go into detail on processes and threads.

Real-world: this is the scheme behind everyday permissions. The file you saved this morning is owned by your UID; your colleagues' group has read access to it; everyone else sees nothing. The operating system checks the requester's identity against the file's access rules on every open — protection enforced at the point of use, which is why the identity must be established before anything else.

Exam Guidance Summary

• Mid-semester: closed-book, two-hour test, covering the topics taught in contact sessions 1 to 8; fixed date announced (March 16). Comprehensive exam: open-book, two-and-a-half-hour test, covering all the topics present in the handout; fixed date announced (Saturday, May 18).
• Assignment: exercises in the CPU-OS simulator, done individually or in groups of at most four members; submit after the mid-semester; a demo is given before the mid-semester.
• Quiz one is conducted before the mid-semester. Any change in dates or times is announced on the portal in advance.

• Importance signals to take into the exam: process scheduling, process synchronization, and deadlock were explicitly flagged as very important topics. Expect the course to return to them in depth.
• Definitions worth having ready: the operating system as a bridge between user and hardware; the four components (hardware, operating system, application programs, users); the resource allocator and control program definitions; the bootstrap program and the kernel; user mode vs. kernel mode and the mode bit; process vs. program; volatile vs. non-volatile memory; the storage hierarchy with the speed and capacity arrows.
• Study advice: download the e-book of Operating System Concepts (Silberschatz) and go through it; go through the recorded sessions on the portal before the contact session; ask doubts as they come — the first session or two are introductory and carry few doubts; and if the pace feels too fast, say so, because there are eight contact sessions to cover the mid-semester portion.

Key Industry Applications

• Real-world: Microsoft dominates today's systems with roughly 64% of usage; Unix or Linux comes next, then the Mac; Android and iOS rule mobile; Solaris belongs to Sun Microsystems. The market split matters because each platform's operating system makes its own design choices — and the course points them out as they come up.
• Real-world: GM-OS was the first operating system, developed by General Motors for IBM machines; Unix, written in C, was developed by Ken Thompson and Dennis Ritchie. The lineage runs unbroken from those two machines to today's systems.
• Real-world: the browser's remote-fetch path — your query travels through the operating system and hardware to a distant server and comes back to your screen. Every search you run exercises the OS's networking and I/O paths.
• Real-world: handheld devices (mobiles, iPads) are optimized for usability and battery life rather than resource utilization; sensors and CCTV sit idle until an event triggers them. The same OS must serve both a phone you hold and a sensor that wakes once a week.
• Real-world: solid-state drives are standard in today's systems — the operating system itself boots from the SSD — but SSDs are expensive, so hard disks, optical discs (CD, DVD, Blu-ray), and magnetic tapes still fill the cheaper tiers of the hierarchy.
• Real-world: multi-core processors from Intel, ARM, and AMD ship in counts like 2, 4, 6, 8, 16, up to 54 or 128 cores; each core has its own registers and cache. That is why your laptop can run a browser, a game, and an editor at once.
• Real-world: VMware runs one operating system on top of another, a practical example of processes and threads executing concurrently — the guest OS itself is just a program from the host OS's point of view.
• Real-world: clusters with a storage area network (SAN) and a distributed lock manager give high availability, with standby machines taking over when a node fails — the architecture behind search engines, banks, and any service that cannot afford downtime.