CS4023 – Operating Systems
(week 5)
Communication models in processes
Threads
Dr. Atif Azad
[email protected]
1
Acknowledgement
• Significant material in this set of lectures has
been borrowed from:
– http://www.cs.berkeley.edu/~kubitron/courses/cs162
/. Copyright © 2010 UCB
– http://cs162.eecs.berkeley.edu. Copyright © 2014
David Culler. Copyright ©2014 UCB.
– http://www.os-book.com . © 2014 Silberschatz et al.
– Dr Patrick Healy at CSIS Department, University of
Limerick.
2
Review – Week 5
• Concurrency requires:
–
–
–
–
Resource multiplexing
Abstraction of a process (Process Control Block)
Context switching
Scheduling
• Operation on processes
– Process creation (fork, wait, execlp)
– Process termination (cascaded, zombie, orphans)
• Interprocess communication
– Shared Memory
– Message Passing
3
Threads
• So far, process has a single thread of
execution
– A single fetch-decode-exec loop.
• Multithreaded Process:
– Multiple fetch-decode-exec loops
– Consider having multiple program counters per
process
– Multiple locations can execute at once
• Multiple threads of control -> threads
• Must then have storage for thread details,
multiple program counters in PCB
Reminder: Concurrent vs Parallel
n
Concurrent execution on single-core system:
n
Parallelism on a multi-core system:
5
Thread: Definitions
• Thus far, each process we saw: single threaded
–
–
–
–
Even when fork(): creates a child process
Multiple processes != multithreaded (not necessarily)
Each of child and parent are protected (unless created by vfork())
Single threaded program: one thread, one protection domain
• Multithreaded process:
– More than 1 thread per protection domain: multiple stacks, registers
(e.g. P.C.)
– But sharing same global data, heap and files; isolated from other
programs
– Each thread is separately schedulable.
– Multi-threaded kernel: multiple threads, sharing kernel data
structures, capable of using privileged instructions
Single and Multithreaded
Processes
•
Threads share code, data and resources (e.g. I/O)
– But independent stack and registers. (Thread Control Block)
•
Two aspects to concurrency:
– Threads, the active part
– Address spaces encapsulate protection: “Passive” part
Recall: Process
Process
A(int tmp) {
if (tmp<2)
B();
printf(tmp);
Memory
Stack
Resources
}
B() {
Sequential
stream of
instructions
C();
}
I/O State
(e.g., file,
socket
contexts)
C() {
A(2);
}
A(1);
…
CPU state
(PC, SP,
registers..)
Stored in OS
Multi-Processing
Process 1
Process 2
Process N
Mem
.
Mem
.
Mem
.
IO
state
IO
state
CPU
state
CPU
state
…
CPU
sched.
IO
state
CPU
state
OS
1 process
at a time
• Switch overhead: high
• Process creation: high
• Protection
– CPU: yes
– Memory/IO: yes
• Sharing overhead:
high (explicit shared
memory/message
processing)
CPU
(1 core)
Single threaded process: a “Heavy Weight” process
In contrast: Threads
Process 1
Process N
threads
Mem
.
IO
state
…
CPU
state
threads
…
CPU
state
Mem
.
IO
state
…
CPU
state
CPU
sched.
CPU
state
OS
1 thread
at a time
CPU
(1 core)
A thread: a “Light Weight” process
• Switch overhead:
low (only CPU state)
• Thread creation: low
• Protection
– CPU: yes
– Memory/IO: No
• Sharing overhead:
low (thread switch
overhead low)
Threads: in Multi-Cores
Process 1
Process N
threads
threads
Mem
.
IO
state
…
CPU
state
…
Mem
.
IO
state
…
CPU
state
CPU
state
CPU
sched.
CPU
state
– CPU: yes
– Memory/IO: No
OS
4 threads at
a time
core 1
Core 2
Core 3
Core 4
A thread: a “Light Weight” process
• Switch overhead:
low (only CPU state)
• Thread creation: low
• Protection
• Sharing overhead:
low (thread switch
overhead low)
CPU
Shared vs. Per-Thread State
Multi-threaded Applications
• Most modern applications are
multithreaded
• Multiple tasks with the application can
be implemented by separate threads
–
–
–
–
Update display (Graphical Front End)
Fetch data
Spell checking
Answer a network request
• Can simplify code, increase efficiency
• Kernels are generally multithreaded
Benefits
• Responsiveness – may allow continued
execution if part of process is blocked,
especially important for user interfaces
• Resource Sharing – threads share resources of
process, easier than shared memory or
message passing
• Economy – cheaper than process creation,
thread switching lower overhead than context
switching
• Scalability – process can take advantage of
multiprocessor architectures
Multicore Programming
• Multicore or multiprocessor systems
putting pressure on programmers,
challenges include:
– Dividing activities
– Balance
– Data splitting
– Data dependency
– Testing and debugging
Multicore Programming (Cont.)
• Types of parallelism
– Data parallelism – distributes subsets of the
same data across multiple cores, same
operation on each
– Task parallelism – distributing threads across
cores, each thread performing unique
operation
• As number of threads grows, so does
architectural support for threading
– CPUs have cores as well as hardware threads
Amdahl’s Law
• Identifies performance gains from adding additional cores
to an application that has both serial and parallel
components
• S is serial portion
• N processing cores
That is, if application is 75% parallel / 25% serial;
from 1  2 cores (i.e N=2)
speedup = 1/ {0.25+ 0.75/2} = 1.6 times
• As N approaches infinity, speedup approaches 1 / S
• Serial portion of an application has disproportionate effect
on performance gained by adding additional cores
User Threads and Kernel Threads
• Threads exist both at kernel and user levels
– For kernel and user purposes.
• Kernel threads - Supported by the Kernel
– Both for kernel functions and to support user threads
• Nearly all modern operating systems support kernel threads:
–
–
–
–
–
Windows
Solaris
Linux
Tru64 UNIX
Mac OS X
• User threads - management done by user-level threads library
– Design issue. To what extent is kernel aware of user threads, and to what extent the
kernel manages the user threads.
– Management includes kernel involvement at thread creation and scheduling.
Multithreading Models: User to kernel
thread mapping
• Many-to-One
• One-to-One
• Many-to-Many
Blocking
• Blocking: waiting for some
thing before proceeding:
– Typically, B executes after A
finishes.
– Forces a sequential
execution.
– Can slow things down. E.g.
f() reads from keyboard.
– Turn it into opportunity:
reschedule
int i = f();
//A
printf(“% d”,i);
//B
20
Direct Memory Access (DMA)
Blocking
I/O Queue (I/O Bound Processes)
e
t
e
t
e
t
e
t
Mem
.
IO
state
Mem
.
IO
state
CPU
state
CPU
state
Ready Queue
e
t
e
t
e
t
e
t
IO: kebrd()
OS
CPU
21
Many-to-One
• Many user-level threads
mapped to single kernel
thread
• Kernel is not aware of
multiple user threads
• Scheduling the responsibility
at user level
• Few systems currently use
this model
• Examples:
– Solaris Green Threads
– GNU Portable Threads
Many-to-1: Threads Purely at User Level
Process 1
Process N
threads
Mem
.
IO
state
…
CPU
state
threads
…
CPU
state
Mem
.
IO
state
…
CPU
state
CPU
state
Scheduler2
Scheduler1
Threads Library
CPU
sched.
Kernel
1 thread at a
time
CPU
(1 core)
• Pro: Scheduling quick
– No syscall
– Process specific
schedulers
• Cons:
– A thread may not yield
– I/O blocks the entire
process: kernel does
not know individual
threads.
– Making all threads CPU
bound => no parallelism
because:
• User level code can not
control multiple cores
• Timesharing gives no
benefit.
One-to-One
• Each user-level thread maps to kernel
thread
• Creating a user-level thread creates a
kernel thread
• More concurrency than many-to-one
• Number of threads per process
sometimes restricted due to overhead
• Thread management  system calls
• Examples
– Windows
– Linux
– Solaris 9 and later
Many-to-Many Model
• Allows many user level
threads to be mapped to
many kernel threads
• Allows the operating
system to create a
sufficient number of
kernel threads
• Solaris prior to version 9
• Windows with the
ThreadFiber package
Two-level Model
• Similar to M:M, except that it allows a user
thread to be bound to kernel thread
• Examples
– IRIX
– HP-UX
– Tru64 UNIX
– Solaris 8 and earlier
• Scheduler Activation:
– Two level of scheduling: can counter each
other
– Scheduler activation coordinates to avoid that
http://www.informit.com/articles/printerfriendly/25075
Thread Libraries
• Thread library provides
programmer with API for creating
and managing threads
• Two primary ways of
implementing
– Library entirely in user space
– Kernel-level library supported by the
OS
Pthreads
• May be provided either as user-level or
kernel-level
• A POSIX standard (IEEE 1003.1c) API for
thread creation and synchronization
• Specification, not implementation
• API specifies behavior of the thread
library, implementation is up to
development of the library
• Common in UNIX operating systems
(Solaris, Linux, Mac OS X)
Pthreads Example
Pthreads Example (Cont.)
Pthreads Code for Joining 10 Threads