Transcript lecture12-sept24

Operating Systems
CMPSC 473
Processes (6)
September 24 2008 - Lecture 12
Instructor: Bhuvan Urgaonkar
Announcements
• Quiz 1 is out and due in at midnight next M
• Suggested reading: Chapter 4 of SGG
• Honors credits
– Still possible to enroll
– Email me if you are interested
– Extra work in projects
•
Done
Overview of ProcessHow a process is born
related Topics
– Parent/child relationship
– fork, clone, …
• How it leads its life
– Loaded: Later in the course
– Executed
• CPU scheduling
• Context switching
• Where a process “lives”: Address space
– OS maintains some info. for each process: PCB
– Process = Address Space + PCB
• How processes request services from the OS
– System calls
•
•
•
•
How processes communicate
Threads (user and kernel-level)
How processes synchronize
How processes die
Done
Done
Partially done
Start today
Finish today
Multi-threading Models
• User-level thread libraries
– E.g., the one provided with Project 1
– Implementation: You are expected to gain this
understanding as you work on Project 1
– Pop quiz: Context switch overhead smaller. Why?
– What other overheads are reduced? Creation? Removal?
• Kernel-level threads
• There must exist some relationship between user
threads and kernel threads
– Why?
• Which is better?
Multi-threading Models: Many-to-one Model
User thread
k
Kernel thread
• Thread management done by user library
• Context switching, creation, removal, etc. efficient (if designed
well)
• Blocking call blocks the entire process
• No parallelism on uPs? Why?
• Green threads library on Solaris
Multi-threading Models: One-to-many Model
User thread
k
k
k
k
Kernel thread
• Each u-l thread mapped to one k-l thread
• Allows more concurrency
– If one thread blocks, another ready thread can run
– Can exploit parallelism on uPs
• Popular: Linux, several Windows (NT, 2000, XP)
Multi-threading Models: Many-to-many Model
User thread
k
k
k
• # u-l threads >= #k-l threads
• Best of both previous approaches?
Kernel thread
Multi-threading Models: Many-to-many Model
(2)
User thread
Kernel thread
k
•
•
•
•
k
k
k
Popular variation on many-to-many model
Two-level model
IRIX, HP-UX, Tru64 UNIX, Older than Solaris 9
Pros? Cons?
Popular Thread Libraries
• Pthreads
– The POSIX standard (IEEE 1003.1c) defining an API
for thread creation and synchronization
– Specification NOT implementation
– Recall 311 and/or Check out Fig 4.6
– You will use this in Project 1
• Win32 threads
• Java threads
– JVM itself is at least a thread for the host OS
– Different implementations for different OSes
Thread-specific Data
• Often multi-thread programs would like to
have each thread have access to some data all
for itself
• Most libraries provide support for this
including Pthreads, Win32, Java’s lib.
Approach #3: User or kernel support to
automatically share code, data, files!
code
registers stack
heap
registers stack
data
registers stack
files
registers stack
In virtual
memory
threads
URL parsing process
Network sending process
Network reception process
Interprets response, composes media
together and displays on browser screen
• E.g., a Web browser
•
Share code, data, files (mmaped), via shared memory mechanisms (coming up)
– Burden on the programmer
•
Better yet, let kernel or a user-library handle sharing of these parts of the address spaces
and let the programmer deal with synchronization issues
– User-level and kernel-level threads
Approach #3: User or kernel support to
automatically share code, data, files!
code
heap
registers stack heap
data
registers stack heap
files
registers stack heap registers stack heap
In virtual
memory
threads
URL parsing process
Network sending process
Network reception process
Interprets response, composes media
together and displays on browser screen
•
E.g., a Web browser
•
Share code, data, files (mmaped), via shared memory mechanisms (coming up)
–
•
Burden on the programmer
Better yet, let kernel or a user-library handle sharing of these parts of the address spaces and let the
programmer deal with synchronization issues
–
User-level and kernel-level threads
Scheduler Activations
User thread
• Kernel provides LWPs that appear like processor
to the u-l library
• Upcall: A way for the kernel to notify an
application about certain events
– Similar to signals
• E.g., if a thread is about to block, kernel makes an
upcall and allocates it a new LWP
LWP Lightweight
• U-l runs an upcall handler that may schedule
process
another eligible thread on the new LWP
• Similar upcall to inform application when the
blocking operation is done
Kernel thread
k
• Read Sec 4.4.6
• Paper by Tom Anderson (Washington) in early 90s
• Pros and cons?
Costs/Overheads of
a Context Switch
• Direct/apparent
– Time spent doing the switch described in previous lectures
– Fixed (more or less)
• Indirect/hidden costs
– Cache pollution
– Effect of TLB pollution (will study this when we get to Virtual
Memory Management)
– Workload dependent
User-level vs Kernel-level Threads
• Make your own list based on previous
lectures
• Potential exam questions here!
Event-driven
Programming
• Asynchronous I/O
• Pros and cons
Interrupts/Traps
• Recap interrupt/trap
– Used to notify the OS that something has happened that it needs to attend to
•
•
•
•
E.g. 1: Network packet arrived at the Ethernet card
E.g. 2: Process made a system call
E.g. 3: Process performed division by zero
E.g. 4: CPU about to melt!
– Interrupt/trap handlers implemented by the OS; their addresses stored at
fixed locations indexed by their numbers
– Usually handled right away
• Linux: Top-half right away, bottom-half at leisure
• Interrupts: Asynchronous generation, synchronous handling
• Traps: Synchronous generation and handling
Interrupts/Traps versus Signals
•
Used to notify the OS that
something has happened that it
needs to attend to
•
Interrupt/trap handlers are
implemented by the OS
•
Usually handled right away
• Used to notify a process that
something has happened that
it needs to attend to
• Signal handlers may be
implemented by the process
• Handled when the process is
scheduled next
• Generated and handled
synchronously
•
Interrupts asynch. generated,
traps synch. generated
– May be due to an asynch.
interrupt, but the signal will
be generated synch. WHY?
Signals
• Signals are a message-passing based IPC mechanism
– Communication between processes
– Communication between kernel and processes
• Fixed number of signals defined by the OS and made known to the processes
– UNIX: signal.h
• A process may implement its own handler for one or more signals
– Allowed for most signals, not allowed for SIGKILL
– Each PCB has indicators for which signals were received and are due
– Upon getting scheduled, the handler for signals received are executed in some order
• Okay from the process point of view since it is unaware of when it is being
scheduled or taken off the CPU
More on signals
• Each signal has a default action which is one of the following:
–
–
–
–
The signal is discarded after being received
The process is terminated after the signal is received
A core file is written, then the process is terminated
Stop the process after the signal is received
• Each signal defined by the system falls into one of five classes:
– Hardware conditions
– Software conditions
– Input/output notification
– Process control
–
Resource control
Examples of signals
•
•
•
•
•
•
•
•
•
SIGHUP 1 /* hangup */
SIGINT 2 /* interrupt */
SIGQUIT 3 /* quit */
SIGILL 4 /* illegal instruction */
SIGABRT 6 /* used by abort */
SIGKILL 9 /* hard kill */
SIGALRM 14 /* alarm clock */
SIGCONT 19 /* continue a stopped process */
SIGCHLD 20 /* to parent on child stop or exit */