Operating Systems CMPSC 473

14
Operating Systems CMPSC 473 Processes (6) September 24 2008 - Lecture 12 Instructor: Bhuvan Urgaonkar

description

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 - PowerPoint PPT Presentation

Transcript of Operating Systems CMPSC 473

Page 1: Operating Systems CMPSC 473

Operating SystemsCMPSC 473Processes (6)

September 24 2008 - Lecture 12

Instructor: Bhuvan Urgaonkar

Page 2: Operating Systems CMPSC 473

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

Page 3: Operating Systems CMPSC 473

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

Page 4: Operating Systems CMPSC 473

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?

Page 5: Operating Systems CMPSC 473

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

Page 6: Operating Systems CMPSC 473

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

Page 7: Operating Systems CMPSC 473

Multi-threading Models: Many-to-many Model

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

kk k Kernel thread

User thread

Page 8: Operating Systems CMPSC 473

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

Page 9: Operating Systems CMPSC 473

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

Page 10: Operating Systems CMPSC 473

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.

Page 11: Operating Systems CMPSC 473

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

Page 12: Operating Systems CMPSC 473

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

Page 13: Operating Systems CMPSC 473

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

Page 14: Operating Systems CMPSC 473

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