1. UNIX Process Creation
Every process, except process 0, is created by the fork() system call
fork() allocates entry in process table and assigns a unique PID to the child process
Child gets a copy of the parent process image
Both child and parent are executing the same code following fork()
Need to invoke execve to load new binary file
fork() returns the PID of the child to the parent process and returns 0 to the child process

2. UNIX System Processes
Process 0 is created at boot time and becomes the “swapper” after forking process 1 (the INIT process)
When a user logs in, process 1 creates a process for that user

3. UNIX Process Image User-level context Register context
Process Text (ie: code: read-only)
Process Data
User Stack (calls/returns in user mode)
Shared memory (for IPC)
only one physical copy exists but, with virtual memory, it appears as it is in the process’s address space
Register context

4. UNIX Process Image System-level context Process table entry
the actual entry concerning this process in the Process Table maintained by OS
Process state, UID, PID, priority, event awaiting, signals sent, pointers to memory holding text, data...
U (user) area
additional process info needed by the kernel when executing in the context of this process
effective UID, timers, limit fields, files in use ...
Kernel stack (calls/returns in kernel mode)
Per Process Region Table (used by memory manager)

5. Process Characteristics
The two characteristics are treated independently by some recent OS
The unit of dispatching is usually referred to a thread or a lightweight process
The unit of resource ownership is usually referred to as a process or task

6. Multithreading vs. Single threading
Multithreading: when the OS supports multiple threads of execution within a single process
Single threading: when the OS does not recognize the concept of thread
MS-DOS support a single user process and a single thread
UNIX supports multiple user processes but only supports one thread per process
Solaris supports multiple threads

7. Threads Has an execution state (running, ready, etc.)
Context is saved when not running
Has an execution stack and some per-thread static storage for local variables
Has access to the memory address space and resources of its process
All threads of a process share this
When one thread alters a (non-private) memory item, all other threads (of the process) sees that
A file opened by one thread, is available to others

8. Single Threaded and Multithreaded Process Models
Thread Control Block contains a register image, thread priority and
thread state information

9. Benefits of Threads vs Processes
Takes less time to create a new thread than a process
Less time to terminate a thread than a process
Less time to switch between two threads within the same process

10. Benefits of Threads Client/Server paradigm
Server may need to handle several file requests over a short period of time
More efficient to create (and destroy) a thread for each request
Multiple threads can execute simultaneously on different processors

11. Application benefits of threads
Consider an application that consists of several independent parts that do not need to run in sequence
Each part can be implemented as a thread
Whenever one thread is blocked waiting for an I/O, execution could possibly switch to another thread of the same application (instead of switching to another process)

12. Benefits of Threads
Since threads within the same process share memory and files, they can communicate with each other without invoking the kernel
Therefore, it becomes necessary to synchronize the activities of various threads so that they do not obtain inconsistent views of the data

13. Threads States Three key states: running, ready, blocked
They have no suspend state because all threads within the same process share the same address space
Indeed: suspending (ie: swapping) a single thread involves suspending all threads of the same process
Termination of a process, terminates all threads within the process

14. User-Level Threads (ULT)
The kernel is not aware of the existence of threads
All thread management is done by the application, using a thread library
Thread switching does not require kernel mode privileges
Scheduling is application specific

15. Threads library Contains code for: Creating and destroying threads
Passing messages and data between threads
Scheduling thread executions
Saving and restoring thread contexts

16. Kernel Activity for ULTs
The kernel is not aware of thread activity but it is still managing process activity
When a thread makes a system call, the whole process will be blocked
For the thread library that thread is still in the running state
So thread states are independent of process states

17. Advantages and inconveniences of ULT
Most system calls are blocking and the kernel blocks processes. So all threads within the process will be blocked
The kernel can only assign processes to processors. Two threads within the same process cannot run simultaneously on two processors
Advantages
Thread switching does not involve the kernel: no mode switching
Scheduling can be application specific: choose the best algorithm.
ULTs can run on any OS. Only needs a thread library

18. Kernel-Level Threads (KLT)
All thread management is done by kernel
No thread library but an API to the kernel thread facility
Kernel maintains context information for the process and the threads
Switching between threads requires the kernel
Scheduling occurs on a thread basis, usually
Ex: Windows NT and OS/2

19. Advantages and inconveniences of KLT
the kernel can simultaneously schedule many threads of the same process on many processors
blocking is done on a thread level
kernel routines can be multithreaded
Inconveniences
thread switching within the same process involves the kernel. We have 2 mode switches per thread switch
this results in a significant slow down

20. Combined ULT/KLT Approaches
Thread creation done in the user space
Bulk of scheduling and synchronization of threads done in the user space
The programmer may adjust the number of KLTs
May combine the best of both approaches
Example: Solaris

21. Solaris
Process includes the user’s address space, stack, and process control block
User-level threads (threads library)
Invisible to the OS
Form the interface for application parallelism
Kernel threads
The unit that can be dispatched on a processor and its structures are maintain by the kernel
Lightweight processes (LWP)
Each LWP supports one or more ULTs and maps to exactly one KLT
Each LWP is visible to the application

22. Process 2 is equivalent to a pure ULT approach
Process 4 is equivalent to a pure KLT approach
We can specify a different degree of parallelism (process 3 and 5)

23. Solaris: versatility
We can use ULTs when logical parallelism does not need to be supported by hardware parallelism (we save mode switching)
Ex: Multiple windows but only one is active at any one time
If threads may block then we can specify two or more LWPs to avoid blocking the whole application

24. Solaris: user-level thread execution
Transitions among these states is under the exclusive control of the application
A transition can occur only when a call is made to a function of the thread library
It’s only when a ULT is in the active state that it is attached to a LWP (so that it will run when the kernel level thread runs)
A thread may transfer to the sleeping state by invoking a synchronization primitive (chap 5) and later transfer to the runnable state when the event waited for occurs
A thread may force another thread to go to the stop state...

25. Solaris: user-level thread states
(attached to a LWP)

26. Decomposition of user-level Active state
When a ULT is Active, it is associated to a LWP and, thus, to a KLT
Transitions among the LWP states is under the exclusive control of the kernel
A LWP can be in the following states:
running: when the KLT is executing
blocked: because the KLT issued a blocking system call (but the ULT remains bound to that LWP and remains active)
runnable: waiting to be dispatched to CPU

27. Solaris: Lightweight Process States
LWP states are independent of ULT states
(except for bound ULTs)

28. Operating System Control Structures
The OS maintains the following tables for managing processes and resources:
Memory tables
I/O tables
File tables
Process tables

29. Process images in virtual memory

30. Location of the Process Image
Each process image is in virtual memory
May not occupy a contiguous range of addresses (depending on the memory management scheme used)
Both a private and shared memory address space is used
Location if each process image is pointed to by an entry in the Primary Process Table
For the OS to manage the process, at least part of its image must be brounght into main memory

31. Process Control Block process pointer state process number
program counter
registers
memory limits
list of open files .

32. PCB Process Identification
A few numeric identifiers may be used
Unique process identifier (always)
Indexes, directly or indirectly, into the primary process table
User identifier
The user who is responsible for the job
Identifier of the parent process that created this process

33. PCB Processor State Information
Contents of processor registers
User-visible registers
Control and status registers
Stack pointers
Program status word (PSW)
Contains status information
Example: the EFLAGS register on Pentium machines

34. PCB Process Control Information
Scheduling and state information
Process state ( i.e: running, ready, blocked...)
Priority of the process
Event for which the process is waiting (if blocked)
Data structuring information
May hold pointers to other PCBs for process queues, parent-child relationships and other structures

35. Execution Modes
To protect PCBs, and other OS data, most processors support at least 2 execution modes:
Privileged mode (a.k.a. system mode, kernel mode, supervisor mode, control mode )
manipulating control registers, primitive I/O instructions, memory management...
User mode
Proper mode is set via a mode bit which can only be set by an interrupt, a trap or OS call

36. interrupt or system call interrupt or system call
CPU Context Switch
process P0
operating system
process P1
interrupt or system call
executing
save state into PCB0
idle
reload state into PCB1
executing
idle
interrupt or system call
save state into PCB1
idle
reload state into PCB0
executing

37. Context Switching Basic Steps
Save context of processor including program counter and other registers
Update the PCB of the running process with its new state and other associate info
Move PCB to appropriate queue - ready, blocked
Select another process for execution
Update PCB of the selected process
Restore CPU context from that of the selected process

38. Process Scheduling Differential responsiveness Fairness Efficiency
Discriminate between different classes of jobs
Fairness
Give equal and fair access to all processes of the same class
Efficiency
Maximize throughput, minimize response time, and accommodate as many users as possible

39. Scheduling Queues
OS maintains queues of processes waiting for resources
Short term queue of processes in memory ready to execute
The dispatcher decides who goes next
Long term queue of new jobs waiting to use the system
OS must not admit too many processes on short-term queue
A queue for each I/O device consisting of processes that want to use that I/O device

40. Ready and I/O Device Queues
queue header
PCB7
PCB2
ready
head
tail
registers
registers
queue
mag
tape
head
tail
unit 0
PCB3
PCB14
PCB6
mag
tape
head
tail
unit 1
disk
head
tail
unit 0
PCB5
terminal
head
tail
unit 0

41. Process Scheduling Queueing Diagram

42. Schedulers Short-term Scheduler Long-term Scheduler Mid-term Scheduler
Also, referred to as dispatcher
Long-term Scheduler
Mid-term Scheduler
Also, referred to as the swapper

43. Short-term Scheduler Dispatcher
Dispatcher selects from among ready processes and allocate the CPU to one of them
It selects the next process according to a scheduling algorithm
It prevents a single process from monopolizing CPU
CPU always executes instructions from the dispatcher when switching from one process to another

44. Long-term Scheduler
This scheduler controls the degree of multiprogramming
The number of processes in memory
It strives to select a good process mix of I/O bound and CPU-bound processes
If the degree of multiprogramming is stable, the average process arrival rate must be equal to the average process departure rate
Thus, long-term scheduler usually gets invoked when a process leaves the system

45. The need for swapping
Even with virtual memory, keeping too many processes in main memory may deteriorate the system’s performance
The OS may need to suspend some processes, ie: to swap them out to disk.
Two new states are added states:
Blocked Suspended: blocked processes which have been swapped out to disk
Ready Suspended: ready processes which have been swapped out to disk