0% found this document useful (0 votes)
3 views4 pages

CSC 308 - Week 3 Lecture Notes

Uploaded by

Lamin Uba Jajee
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
3 views4 pages

CSC 308 - Week 3 Lecture Notes

Uploaded by

Lamin Uba Jajee
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

CSC 308: Operating Systems

Week 3: Processes and Threads


1. The Process Concept

A basic definition of a process is a program in execution. However, it is crucial to distinguish


between a program and a process.
●​ Program: A passive entity, such as a file containing a list of instructions stored on disk (an
executable file).
●​ Process: An active entity, with a program counter specifying the next instruction to
execute and a set of associated resources. A program becomes a process when an
executable file is loaded into memory.
Memory Layout of a Process

When a process is loaded into main memory, it is typically divided into multiple distinct
sections:
1.​ Text Section: The compiled program code (executable instructions).
2.​ Data Section: Global and static variables initialized by the programmer.
3.​ Heap: Memory that is dynamically allocated during run time (e.g., using malloc() in C or
new in Java). The heap grows upwards.
4.​ Stack: Temporary data storage for function parameters, return addresses, and local
variables. The stack grows downwards.​
(Note: If the Stack and Heap grow too much and collide, the OS will trigger a "Stack
Overflow" or "Out of Memory" error and terminate the process.)
2. Process State and the PCB

As a process executes, it changes state. The state of a process is defined in part by its current
activity.
The Five-State Model

1.​ New: The process is being created (memory is being allocated, PCB is being built).
2.​ Ready: The process is waiting to be assigned to a processor. It has all the resources it
needs except CPU time.
3.​ Running: Instructions are being executed by the CPU. (On a single processor, only one
process can be running at a time).
4.​ Waiting (Blocked): The process is waiting for some event to occur (such as an I/O
completion or the reception of a signal). It cannot run even if the CPU is free.
5.​ Terminated: The process has finished execution and its resources are being reclaimed
by the OS.
The Process Control Block (PCB)

To manage the hundreds of processes running concurrently, the OS maintains a data structure
for each process called the Process Control Block (PCB) or Task Control Block. The PCB serves
as the repository for any information that may vary from process to process:
●​ Process State: The current state (New, Ready, Running, etc.).
●​ Program Counter: The address of the next instruction to be executed.
●​ CPU Registers: The contents of the accumulator, index registers, stack pointers, and
condition codes. (These must be saved when an interrupt occurs).
●​ CPU-Scheduling Information: Process priority, pointers to scheduling queues.
●​ Memory-Management Information: The value of the base and limit registers, page
tables, or segment tables.
●​ Accounting Information: Amount of CPU time used, time limits, process ID (PID).
●​ I/O Status Information: The list of I/O devices allocated to the process, a list of open
files.
3. Process Scheduling and Context Switching

The objective of multiprogramming is to have some process running at all times to maximize
CPU utilization. The objective of time-sharing is to switch the CPU among processes so
frequently that users can interact with each program while it is running.
Scheduling Queues

As processes enter the system, they are put into various queues:
●​ Job Queue: Set of all processes in the system.
●​ Ready Queue: Set of all processes residing in main memory, ready and waiting to
execute.
●​ Device Queues: Set of processes waiting for a specific I/O device.
The Context Switch

When an interrupt or system call occurs, the OS must pause the currently running process and
switch to another. This mechanism is called a Context Switch.
1.​ The OS stops the running Process A.
2.​ The OS saves the exact state of the CPU (Program Counter, Registers) into Process A's
PCB.
3.​ The OS selects Process B from the Ready Queue.
4.​ The OS loads the saved state from Process B's PCB into the CPU hardware.
5.​ Process B begins execution from exactly where it left off.
Performance Note: Context-switch time is pure overhead; the system does no useful work
while switching. Its speed varies heavily depending on the memory speed, the number of
registers that must be copied, and whether special hardware instructions exist (like multiple
sets of registers).
4. Operations on Processes
Process Creation

Processes can create new processes. The creator is the parent process, and the new
processes are children.
●​ In UNIX/Linux, this is done using the fork() system call. fork() creates an exact clone of the
parent's memory space. Both processes continue executing from the instruction
immediately following the fork().
●​ Typically, the child immediately calls the exec() system call, which overwrites the child's
memory space with a brand new program.
Process Termination

A process terminates when it finishes executing its final statement and asks the operating
system to delete it by using the exit() system call.
●​ The parent may wait for the child to terminate using the wait() system call.
●​ Zombie Process: A child process that has terminated, but whose parent has not yet
called wait(). The child's resources are freed, but its entry in the OS process table
remains.
●​ Orphan Process: A child process whose parent has terminated without calling wait(). In
Linux, orphan processes are adopted by the init process (PID 1), which periodically calls
wait() to clean them up.
5. Threads

If a process is a way to group resources (memory, open files), a Thread is the entity scheduled
for execution on the CPU. A thread is often called a lightweight process.
Traditional processes have a single thread of control. If a process has multiple threads of
control, it can perform more than one task at a time (e.g., a web browser having one thread
display images while another thread fetches data from the network).
Anatomy of a Thread

What does a thread share, and what does it keep to itself?


●​ Private to the Thread: Thread ID, Program Counter, Register Set, and a local Stack.
●​ Shared with other Threads in the same Process: The Code section (Text), Data section
(globals), Heap memory, and OS resources like open files and signals.
Benefits of Multithreading

1.​ Responsiveness: Multithreading an interactive application may allow a program to


continue running even if part of it is blocked (e.g., waiting for I/O).
2.​ Resource Sharing: Threads share the memory and the resources of the process to
which they belong by default, unlike IPC which requires developer intervention.
3.​ Economy: Allocating memory and resources for process creation is costly. Because
threads share these resources, it is much more economical to create and context-switch
threads.
4.​ Scalability: The benefits of multithreading can be greatly increased in a multiprocessor
architecture, where threads may be running in parallel on different processing cores.
6. Multithreading Models

Support for threads may be provided either at the user level (User Threads) or by the kernel
(Kernel Threads).
●​ User Threads: Managed by a user-level threads library (e.g., POSIX Pthreads). The kernel
is unaware of them. They are extremely fast to create and switch, but if one user thread
blocks (e.g., waits for disk I/O), the kernel blocks the entire process, stopping all other
threads.
●​ Kernel Threads: Supported and managed directly by the OS. The kernel performs thread
creation, scheduling, and management. Slower to create than user threads, but if one
blocks, the kernel can schedule another thread from the same process.
The Mapping Models

How do user threads map to kernel threads?


1.​ Many-to-One Model: Maps many user-level threads to one kernel thread. Thread
management is efficient, but true concurrency is impossible on a multicore system
because the kernel can only schedule one thread at a time.
2.​ One-to-One Model: Maps each user thread to a kernel thread (used by Linux and
Windows). Provides more concurrency, allowing another thread to run when a thread
makes a blocking system call. The drawback is the overhead of creating a kernel thread
for every user thread.
3.​ Many-to-Many Model: Multiplexes many user-level threads to a smaller or equal
number of kernel threads. Offers the best of both worlds, but is extremely complex to
implement in the OS scheduler.

You might also like