Operating SystemsCMPSC 473Processes (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

Overview of Process-related

Topics• How a process is born

– 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

Partially done

Done

Done

Finish todayStart 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

• 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

k Kernel thread

User thread

Multi-threading Models: One-to-many Model

• 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)

k k k k Kernel thread

User thread

Multi-threading Models: Many-to-many Model

• # u-l threads >= #k-l threads• Best of both previous approaches?

kk k Kernel thread

User thread

Multi-threading Models: Many-to-many Model (2)

• Popular variation on many-to-many model• Two-level model• IRIX, HP-UX, Tru64 UNIX, Older than Solaris 9

• Pros? Cons?

kk k k

Kernel thread

User thread

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!

• 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

URL parsing processNetwork sending processNetwork reception processInterprets response, composes mediatogether and displays on browser screen

In virtualmemory

code data files

registersstack

heap

registersstack registersstack registersstack

threads

Approach #3: User or kernel support to automatically share code, data,

files!

URL parsing processNetwork sending processNetwork reception processInterprets response, composes mediatogether and displays on browser screen

In virtualmemory

code data files

registersstack

heap

registersstack registersstack registersstack

threads

heap heap heap heap

• 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

• 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

• U-l runs an upcall handler that may schedule another eligible thread on the new LWP

• Similar upcall to inform application when the blocking operation is done

• Read Sec 4.4.6• Paper by Tom Anderson (Washington) in

early 90s• Pros and cons?

k

LWP

Kernel thread

User thread

Lightweightprocess

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

• Interrupts asynch. generated, traps synch. generated

• 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– 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

*/