Processes and Threads
Learn how a program differs from a process, how processor time is shared and what threads are. Understand the risks of shared memory: race conditions and deadlocks.
All topics (1 of 2)
Chapter 1. Operating systems
Chapter 2. Network technologies
A program is a passive set of code and data stored on disk, while a process is its running instance. The operating system gives every process its own address space (code, data, heap and stack) and a list of open files, and keeps information about the process in a process control block (PCB). As a result, one process cannot directly change the memory of another, which keeps the system stable and secure.
During its life, a process passes through several states: new, ready, running, waiting (for example, for a disk operation to finish) and terminated. The scheduler shares processor time among processes; one of the simplest algorithms is Round Robin, in which every process in turn receives a short time slice. Handing the processor from one process to another is called a context switch: the registers and the PCB are saved and those of the new process are restored, and no useful work is done in the meantime.
A thread is a unit of execution inside a process. The threads of one process share the address space and open files, but each has its own stack, registers and program counter. For this reason, creating threads and switching between them is cheaper than for processes, and exchanging data is easier. On a multi-core processor threads can truly run in parallel, while on a single core they take turns.
Shared memory is convenient but dangerous: if two threads change the same variable at the same time, the result depends on the order of execution, which is called a race condition. For example, the operation counter += 1 actually consists of three steps: read the value, add one and write it back; if two threads interleave these steps, one increment is lost. Synchronization tools such as mutexes and semaphores protect shared data, but using them incorrectly can cause a deadlock, in which each thread waits for a resource held by another.
Key takeaways
- A program is passive code on disk; a process is its running instance with its own address space.
- A process moves through the new, ready, running, waiting and terminated states; a context switch costs time.
- Threads share the memory and files of their process, but each has its own stack and registers.
- Changing shared data without synchronization leads to a race condition; mutexes and semaphores prevent it.
- Incorrect synchronization can cause a deadlock.
Practice tasks
- In a Linux terminal run
ps aux(Task Manager on Windows) and write the PID, state (STAT) and memory use (RSS) of at least five processes into a table. - In Python, use
threadingto create two threads: each reads the shared variablecounter, adds one aftertime.sleep(0)and writes it back, repeating this 10000 times. Notice that the final value is less than the expected 20000, then fix the error withthreading.Lock. - With the command
ps -eLf(theNLWPcolumn shows the number of threads) find out how many threads the browser processes have, and explain why a browser often opens each tab in a separate process.
Review questions
Test yourself: think first, then reveal the answer.
1What is the main difference between a process and a thread?Show answerHide answer
A process has its own address space and is isolated from other processes; the threads of one process share memory and open files, and only their stacks and registers are separate.2Why can context switching reduce performance?Show answerHide answer
Each time the processor state (registers, PCB) is saved and another one restored, and the data in the cache may become useless; no useful work is done in the meantime.3When does a race condition occur and how can it be prevented?Show answerHide answer
It occurs when two or more threads change shared data without synchronization; it is prevented by protecting the critical section with a mutex or a semaphore.
0 of 2 topics completed
Sign in to mark