CS5460: Operating Systems Lecture 5: Processes and Threads - - PowerPoint PPT Presentation

CS 5460: Operating Systems Lecture 5

CS5460: Operating Systems

Lecture 5: Processes and Threads

(Chapters 3-4)

Context Switch Results

 lab2-15 3.8 us  gamow 1.6 us  home 1.0 us  VirtualBox on lab2-25 170 us  VirtualBox on gamow 4.6 us  VirtualBox on home 42 us

CS 5460: Operating Systems Lecture 5

Important From Last Time

 Process state machine

– Interaction with OS invariants

 Process control block

– Presence on OS queues

 Process creation

– UNIX vs. Windows style

 Process termination

CS 5460: Operating Systems Lecture 5

Terminated New Ready Running Waiting

create process exit process schedule deschedule block on timer, I/O, page fault, … I/O done

 What does this program print?

#include <stdio.h> #include <unistd.h> int main (void) { int x = 1000; fork(); printf (“%d\n”, x++); printf (“%d\n”, x++); return 0; }

CS 5460: Operating Systems Lecture 5

CS 5460: Operating Systems Lecture 5

Termination

 When process dies,

OS reclaims its resources

 On Unix: – A process can terminate itself using exit() system call – A process can kill another process using the kill() system call

#include <signal.h> #include <unistd.h> #include <stdio.h> int main(void) { int cid = fork(); if (cid == 0) { sleep(10); printf(“Child exiting!\n”); exit(0); } else { printf(“Type to kill child\n”); char answer[10]; gets(answer); if (!kill(cid,SIGKILL)) { printf(“Child dead!\n”); } } }

CS 5460: Operating Systems Lecture 5

 pid_t wait(int *status): – Parent process use wait() to request notification when a child dies – Returns PID of dead child; sets status to be child’s exit code – Works regardless of whether child dies before/ after call  What does this

program do?

#include <signal.h> #include <unistd.h> #include <stdio.h> int main(void) { int ret, cid; cid = fork(); if (cid == 0) { /* CHILD*/ printf(“Child exiting.\n”); exit(100); } else { /* PARENT */ wait(&ret); printf(“Status: %d\n”, ret); } }

What happens when a process dies? Do we reclaim all resources?

CS 5460: Operating Systems Lecture 5

 Context switch: Switch from one process/thread

running on CPU to another

– When can it happen? – Which process/thread should run next? – How is it accomplished?  When? Preemptive vs non-preemptive scheduling – Can occur whenever the kernel (scheduler) gains control of CPU  Which? Scheduler decides based on its policies  How? – Save state of “old” process – Restore state of “new” process – Question: What constitutes the process’s “state”?

CS 5460: Operating Systems Lecture 5

P2

Timeline of a Context Switch

P1 PN P1

Save/restore cpu state Save/restore cpu state

Scheduler (P1) Scheduler (P1) Scheduler (P2) Scheduler (PN) Interrupt

• r trap

Interrupt

• r trap

int/trap handler One instr later! int/trap handler

Return from trap/int (P2)

TIME Question: What parts of timeline execute in kernel mode?

CS 5460: Operating Systems Lecture 5

Introducing Threads

 Processes are “heavyweight” – Memory mappings: may be expensive to swap – Cache/TLB state: flushing expensive, especially side effects – Lots of kernel state – Context switching between processes is expensive  Threads are “lightweight” – Multiple threads share process state

» Same address space » Same open file/socket tables

– Goal: make context switching between threads cheap – Not all OSes support threads efficiently (e.g., older Unixes)

» Had to fake it using things like select() and signal()

What Are Threads Good For?

• 1. Making apps speed up on a multicore

– (Bad) alternative to using threads: Use multiple single-threaded processes

• 2. Creating servers with a lot of internal concurrency
• 3. Letting programmers express somewhat

independent computations within an address space

• 4. Letting programmers create the hardest debugging

programs EVER

– Race conditions – Deadlocks – Etc.

CS 5460: Operating Systems Lecture 5

CS 5460: Operating Systems Lecture 5

 Threads separate process into two abstractions: – Shared resources: address space, kernel resources, privileges – Execution state: PC, SP, PSW, other registers, stack, …

Address space

Thread

DOS, small embedded systems Real-time OSes, Java Older (unthreaded) UNIX Multihreaded OSes (Win7, OS X, Linux)

Add Multi- threading Add multiprogramming

CS 5460: Operating Systems Lecture 5

Implementing Threads

 Address space shared by threads

– Code – Data and heap

 Thread private state:

– Registers (inc. pc, sp, psw) – Stack

 Key issue:

– How do you safely access “shared” state?

» Read-only (e.g., code) à à easy » Writable à à hard

– Whole section of course dedicated to this

» Synchronization » Concurrency control

 Context switch between threads

– Save/restore registers (tricky)

Code: Data:

SP0

Stack:

HP PC0 PC1 SP1

Stack:

CS 5460: Operating Systems Lecture 5

Kernel Threads vs User Threads

 Kernel threads: – OS supports threads directly – Each thread has separate OS state (ready, blocked,…) – Kernel schedules threads rather than processes – Kernel context switches between threads (and processes)

» Thread switch: save/restore registers (inc. PC and SP) » Process switch: above plus MMU/TLB state » Thread switches cheaper than process (~10us vs ~30us)

 User threads: – OS does not directly support threads – User-level thread library implements threads – Thread “context switch” performed entirely within user space – Cannot get parallelism on a multicore!  Solaris operating system uses both

CS 5460: Operating Systems Lecture 5

Kernel Threads vs User Threads

 Advantages of kernel threads – Threads can exploit multiprocessors – Blocking I/O does not stall non-blocked threads  Advantages of user threads – Faster to create, manipulate, and synchronize – In theory, can tailor scheduling policy to match application need  Alternative to threads à

à event-based programming

– See Ousterhout’s paper: “Why Threads Are a Bad Idea” – Getting concurrency right is hard à à events simplify model

» Race conditions, deadlocks, livelocks, …

– Downside: events are also difficult, and prevent running on multiple processors

CS 5460: Operating Systems Lecture 5

Cooperating Processes vs.Threads

 Cooperating processes can provide benefits: – Improved performance by overlapping activities (parallelism) – Simpler program structure by separating activities (web server) – Fault isolation (e.g., shell, CGI subsystem of web server)

» Example: Apache, Google Chrome

 Problems arise: – New failure modes introduced à à concurrency control – Errors may be harder to debug – Cleanup complicated à à cannot just destroy single process  Questions to consider: – How do cooperating processes communicate? – Do the processes need to share the same {language, machine, OS}?

CS 5460: Operating Systems Lecture 5

IPC via Message Passing

 Option 1: processes exchange “messages” – Need to be able to name other process (e.g., PID) – Some form of msgsnd() and msgrecv() supported by OS

main() { … if (!fork()) producer(); else consumer(); } producer() { while (1) { … produce item nextp; … msgsnd(nextp, consPID); } } consumer() { while (1) { msgrcv(nextc {, prodPID}); … consume item nextc; … } }

CS 5460: Operating Systems Lecture 5

IPC via Shared Memory

 Option 2: processes directly access same memory – Need mechanism to establish shared mappings (e.g., threads in same process, mmap() , shmget()).

main() { … buffer = shmget( … ); in = out = 0; if (!fork()) producer(); else consumer(); } producer() { while (1) { produce item nextp; … while ((in+1)mod N)== out); buffer[in] = nextp; in = (in+1) mod N; } } consumer() { while (1) { while (in == out); nextc = buffer[out];

• ut = (out+1) mod N;

… consume item nextc; … } }

Shared also (not shown)

 Which is more efficient, shared

memory or message passing?

 What are possible problems with this

solution?

CS 5460: Operating Systems Lecture 5

Important From Today

 Processes and threads: – Encapsulate resources and accounting – Threads separate “execution context” from process abstraction – Typical address space layout – Context switch – Kernel threads versus User threads  How do threads communicate (within a process)?  How to cooperating processes communicate?  Synchronization is hard and important  Next up: Scheduling – How to decide what to run next