60SCI026: Exploring Computer Science

Lecture 2: Operating systems

Visiting lecturer: Bùi Văn Thạch

bvthach@[Link]
15/09/2025 – 16/01/2026 1
Objectives
1. Understand the Role of an Operating System.

2. Explore OS Functions.

3. Examine OS Structures.

4. Compare Different Operating Systems.

2
Course topics
1. Overview of Computer Science 6. Computer Vision

2. Operating systems 7. Natural language processing

3. Theoretical Computer Science 8. Machine Learning and Artificial

4. Networks Intelligence

5. Software engineering 9. Digital transformation

10. Recent trends in Computer Science

3
Outline

• What is an Operating System?

• Major OS components

• Types of OS

Reference: Silberschatz Chapter 1 & 3 (3.1-3.4)

4
Outline

• What is an Operating System?

• Major OS components

• Types of OS

Reference: Silberschatz Chapter 1 & 3 (3.1-3.4)

5
Abstract View of System Components (1/2)
application (user)

operating system

hardware

• A software layer between the hardware and the application programs/users, which
provides a virtual machine interface: easy and safe
• A resource manager that allows programs/users to share the hardware resources:
fair and efficient
• A set of utilities to simplify application development.
6
Abstract View of System Components (2/2)

7
Why Do We Want An OS?
• Benefits for application developers
Easier to write programs
See high level abstractions instead of low-level hardware details

E.g. files instead of disk blocks

Portability

• Benefits for users

Easier to use computers
Can you imagine trying to use a computer without the OS?

Safety
OS protects programs from each other

OS protects users from each other

8
Outline

• What is an Operating System?

• Major OS components

• Types of OS

Reference: Silberschatz Chapter 1 & 3 (3.1-3.4)

9
Mechanism And Policy
application (user)

operating system: mechanism+policy

hardware

• Mechanisms: data structures and operations that implement an abstraction (e.g. the
buffer cache).
• Policies: the procedures that guide the selection of a certain course of action from among
alternatives (e.g. the replacement policy for the buffer cache)
• Want to separate mechanisms and policies as much as possible
– Different policies may be needed for different operating environments.
10
Basic computer structure

CPU Memory

memory bus

I/O bus

disk Net interface

11
System Abstraction: Processes
• A process is a system abstraction:
illusion of being the only job in the system

user: run application create, kill processes,

operating system: process inter-process comm.
Multiplexing resources
hardware: computer

12
Processes: Mechanism and Policy
• Mechanism:

Creation, destruction, suspension, context switch, signaling, IPC, etc.

• Policy:

Minor policy questions:

Who can create/destroy/suspend processes?

How many active processes can each user have?

Major policy question that we will concentrate on:

How to share system resources between multiple processes?

Typically broken into a number of orthogonal policies for individual resources such as CPU, memory, and disk.

13
Processor Abstraction: Threads
• A thread is a processor abstraction: illusion of having 1 processor per
execution context

application: execution context

create, kill, synch.
operating system: thread
context switch
hardware: processor

14
Threads: Mechanism and Policy
• Mechanism:
– Creation, destruction, suspension, context switch, signaling, synchronization, etc.

• Policy:
– How to share the CPU between threads from different processes?

– How to share the CPU between threads from the same process?

– How can multiple threads synchronize with each other?

– How to control inter-thread interactions?

• Can a thread murder other threads at will?

15
Memory Abstraction: Virtual memory
• Virtual memory is a memory abstraction: illusion of large contiguous memory,
often more memory than physically available

application: address space

virtual addresses
operating system: virtual memory
physical addresses
hardware: physical memory

16
Virtual Memory: Mechanism
• Mechanism:

Virtual-to-physical memory mapping, page-fault, etc.

virtual address spaces

p1 p2
processes:

v-to-p memory mappings

physical memory:

17
Virtual Memory: Policy
• Policy:
– How to multiplex a virtual memory that is larger than the physical memory onto what is
available?

– How should physical memory be allocated to competing processes?

– How to control the sharing of a piece of physical memory between multiple processes?

18
Storage Abstraction: File System
• A file system is a storage abstraction: illusion of structured storage space

application/user: copy file1 file2 naming, protection,

operations on files
operating system: files, directories
operations on disk
hardware: disk blocks...

19
File System
• Mechanism:
– File creation, deletion, read, write, file-block-to-disk-block mapping, file buffer cache, etc.

• Policy:
– Sharing vs. protection?

– Which block to allocate?

– File buffer cache management?

20
Communication Abstraction: Messaging
• Message passing is a communication abstraction: illusion of reliable
(sometime ordered) transport

application: sockets
naming, messages
operating system: TCP/IP protocols
network packets
hardware: network interface

21
Message Passing
• Mechanism:

– Send, receive, buffering, retransmission, etc.

• Policy:

– Congestion control and routing

– Multiplexing multiple connections onto a single NIC

22
Character & Block Devices
• The device interface gives the illusion that devices support the same API –
character stream and block access

application/user: read character naming, protection,

from device read,write
operating system: character &
block API hardware specific
PIO, interrupt
hardware: keyboard, mouse,
handling, or DMA
etc.

23
Devices
• Mechanisms

– Open, close, read, write, ioctl, etc.

– Buffering

• Policies

– Protection

– Sharing?

– Scheduling?

24
Windows 2000 Block Diagram

25
Major Issues In OS Design (1/2)
• Programming API: what should the VM look like?

• Resource management: how should the hardware resources be multiplexed among

multiple users?

• Sharing: how should resources be shared among multiple users?

• Security: how to protect users from each other? How to protect programs from each
other? How to project the OS from applications and users?

• Communication: how can applications exchange information?

• Structure: how to organize the OS?

• Concurrency: how do we deal with the concurrency that’s inherent in OS’es?

26
Major Issues In OS Design (2/2)
• Performance: how to make it all run fast?

• Reliability: how do we keep the OS from crashing?

• Persistence: how can we make data last beyond program execution?

• Accounting: how do we keep track of resource usage?

• Distribution: how do we make it easier to use multiple computers in conjunction?

• Scaling: how do we keep the OS efficient and reliable as the imposed load and so
the number of computers grow?

27
Outline

• What is an Operating System?

• Major OS components

• Types of OS

Reference: Silberschatz Chapter 1 & 3 (3.1-3.4)

28
Migration of OS Concepts and Features

29
Brief OS History
• In the beginning, there really wasn’t an OS
– Program binaries were loaded using switches

– Interface included blinking lights (cool!)

• Then came batch systems

– OS was implemented to automatically transfer control from one job to the next

– OS was always resident in memory

• Resident monitor

– Operator provided machine/OS with a stream of programs with delimiters

• Typically, input was a card reader back then so delimiters were known as control cards

30
Spooling
• CPUs were much faster than card readers and printers
• Disks were invented – disks were much faster than card readers and printers
• So, what do we do? Indirect and pipeline … what else?
– Read job 1 from cards to disk. Run job 1 while reading job 2 from cards to disk; save
output of job 1 to disk. Print output of job 1 while running job 2 while reading job 3
from cards to disk. And so on …
– This is known as spooling: Simultaneous Peripheral Operation On-Line
• The use of acronyms were alive and well even back then
• Can use multiple card readers and printers to keep up with CPU if needed
• Improves both system throughput and response time

31
Multiprogramming (1/2)
• CPUs were still idle whenever an executing program needed to interact with a peripheral device

– Reading more data from tape

• Multiprogrammed batch systems were invented

– Load multiple programs onto disk at the same time (later into memory)

– Switch from one job to another if when the first job performs an I/O operation

• Peripheral being used had better be slower than disk (or memory)

– Overlap I/O of one job with the computation of another job

– Peripherals have to be asynchronous

– Have to know when I/O operation is done: interrupt vs. polling

• Increase system throughput, possibly at the expense of response time

– When is this better for response time? When is it worse for response time?
32
Multiprogramming (2/2)

P1 Run Wait Run Wait

Wait Run Wait Run Wait

P2

P3 Wait Run Wait Run Wait

P1, P2, P3 Run Run Run Wait Run Run Run Wait

33
Time-Sharing
• As you can imagine, batching was a big pain

– You submit a job, you twiddle your thumbs for a while, you get the output, see a bug, try to figure out what
went wrong, resubmit the job, etc.

– Even running production programs was difficult in this environment

• Technology got better: can now have terminals and support interactive interfaces

• How to share a machine (remember, machines were expensive back then) between multiple people and still
maintain an interactive user interface?

• Time-sharing

– Connect multiple terminals to a single machine

– Multiplex machine between multiple users

– The machine has to be fast enough to give the illusion that each user has his/her own machine

– Multics was the first large time-sharing system – mid-1960’s 34

Time-sharing

P1

P2

P3

Normal Time P1 Completed

interval I/O Started by P1

35
Parallel OS
• Some applications are comprised of tasks that can be executed simultaneously

– Weather prediction, scientific simulations, and recalculation of a spreadsheet

• Can speed up execution by running these tasks in parallel on many processors

• Need OS and language support for dividing programs into multiple parallel
activities

• Need OS support for fast communication and synchronization

• Many different parallel architectures

• Want performance, performance, and portability

36
Real-Time OS
Running applications have time deadlines by which they have to complete certain tasks

• Hard real-time system

– Medical imaging systems, industrial control systems, etc.

– Catastrophic failure if you miss a deadline

• What happens if collision avoidance software on an oil tanker does not detect another ship before the “turning or
breaking” distance of the tanker?

– Challenge lies in how to meet deadlines with minimal resource waste

• Soft real-time system

– Multimedia applications

– May be annoying, but it is not catastrophic if a few deadlines are missed

– The challenge lies in how to meet most deadlines with minimal resource waste

– Challenge also lies in how to load-shed if it becomes overloaded

37
Distributed OS
• Clustering
– Use multiple small machines to handle large service demands

– Cheaper than using one large machine

– Better potential for reliability, incremental scalability, and absolute scalability

• Wide area distributed systems

– Allow use of geographically distributed resources, e.g., use of a local PC to access web services

– Don’t have to carry the needed information with us

• Need OS support for communication and sharing of distributed resources

– E.g., network file systems

• Want performance (although speedup is not a metric of interest here), high reliability, and use of diverse

resources

38
Embedded OS
• Pervasive computing
– Right now, cell phones and PDAs
– Future, computational elements everywhere

• Characteristics
– Constrained resources: slow CPU, small memories, no disk, etc.
– What’s new about this? Isn’t this just like the old computers?
• Well no, because we want to execute more powerful programs than we use to

– How can we execute more powerful programs if our hardware is similar to old hardware?
• Use many, many of them
• Augment with services running on powerful machines

• OS support for power management, mobility, resource discovery, etc.

39
Q&A

40