CS444/CS544Operating Systems

Threads

1/29/2007

Prof. Searleman

jets@clarkson.edu

CS444/CS544 Spring 2007

Cooperating Processes Threads

Reading assignment: Chapter 4

HW#2: system call

Recap: Processes A process includes

Address space (Code, Data, Heap, Stack) Register values (including the PC) Resources allocated to the process

Memory, open files, network connections How to create a process

Initializing the PCB and the address space (page tables) takes a significant amount of time

Interprocess communication IPC is costly also Communication must go through OS (“OS has to guard any

doors in the walls it builds around processes for their protection”)

Windows Process Creation

BOOL CreateProcess( LPCTSTR lpApplicationName, // name of executable module LPTSTR lpCommandLine, // command line string LPSECURITY_ATTRIBUTES lpProcessAttributes, // SD LPSECURITY_ATTRIBUTES lpThreadAttributes, // SD BOOL bInheritHandles, // handle inheritance option DWORD dwCreationFlags, // creation flags LPVOID lpEnvironment, // new environment block LPCTSTR lpCurrentDirectory, // current directory name LPSTARTUPINFO lpStartupInfo, // startup information LPPROCESS_INFORMATION lpProcessInformation // process information );

Windows vs Unix

Windows doesn’t maintain quite the same relationship between parent and child Later versions of Windows have concept of “job”

to mirror UNIX notion of parent and children (process groups)

Waiting for a process to complete? WaitforSingleObject to wait for completion GetExitCodeProcess ( will return STILL_ALIVE

until process has terminated)

Cooperating Processes

Processes can run independently of each other or processes can coordinate their activities with other processes

To cooperate, processes must use OS facilities to communicate One example: parent process waits for child Many others

Files (You’ve Used) Sockets (Networks) Pipes (Like Sockets for local machine; Pair of files) Signals (Today) Shared Memory Events Remote Procedure Call

Signals

Processes can register to handle signals with the signal function void signal (int signum, void (*proc) (int))

Processes can send signals with the kill function kill (pid, signum)

System defined signals like SIGHUP (0), SIGKILL (9), SIGSEGV(11) In UNIX shell, try: “kill –9 pidOfVictimProcess”

Signals not used by system like SIGUSR1 and SIGUSR2 Note: sigsend/sigaction similar to kill/signal

Signalsif (signal(SIGUSR1, sig_handler) == SIG_ERR) fprintf(stderr, "Unable to create handler for SIGUSR1\n");

if (signal(SIGUSR2, sig_handler) == SIG_ERR) fprintf(stderr, "Unable to create handler for SIGUSR2\n");

parentPid = getpid();fprintf(stdout, "Parent process has id %d\n", parentPid);fprintf(stdout, "Parent process forks child...\n");

childPid = fork();if (childPid == 0){ doChild();} else { doParent();}

doChildvoid doChild() { /* I am the child */ myPid = getpid(); assert(myPid != parentPid); fprintf(stdout, "In child (id %d) , Child process has id %d\n", myPid, myPid);

/* send a SIG_USR1 to the parent */ fprintf(stdout, "Child process (id %d) sending 1st SIGUSR1 to parent process (id %d)\n", myPid, parentPid);

err = kill(parentPid, SIGUSR1); if (err){ fprintf(stderr, "Child process (id %d) is unable to send SIGUSR1 signal to the parent process (id %d)\n",

myPid, parentPid); }}

doParent

void doParent() {myPid = getpid();

assert(myPid == parentPid);

fprintf(stdout, "In parent (id %d) , child process has id %d\n", myPid, childPid);

fprintf(stdout, "Parent process (id %d) sending 1st SIGUSR2 to child process (id %d)\n", myPid, childPid);

err = kill(childPid, SIGUSR2); if (err){ fprintf(stderr, "Parent process (id %d) is unable to send SIGUSR2 signal to the child process (id %d)\n", myPid, childPid); } }

sigHandler

static void sig_handler(int signo){ switch(signo){ case SIGUSR1: /* incoming SIGUSR1 signal */ handleSIGUSR1(); break; case SIGUSR2: /*incoming SIGUSR2 signal */ handleSIGUSR2(); break; case SIGTERM: /* incoming SIGTERM signal */ handleSIGTERM(); break; } return;}

handleSIGUSR1

void handleSIGUSR1(){ numSIGUSR1handled++; if (myPid == parentPid){ fprintf(stdout, "Process %d: Parent Received SIGUSR1 %u\n", myPid, numSIGUSR1handled);

} else { fprintf(stdout, "Error: Process %d: Received SIGUSR1, but I am not the parent!!\n", myPid); exit(1);

} #if RECEIVE_MORE_THAN_ONE_SIGNAL if (signal(SIGUSR1, sig_handler) == SIG_ERR){ fprintf(stderr, "Unable to reset handler for SIGUSR1\n");

} #endif }

Sockets A socket is an end-point for communication

over the network Create a socket

int socket(int domain, int type, int protocol)

Type = SOCK_STREAM for TCP Read and write socket just like files Can be used for communication between two

processes on same machine or over the network

Pipes

Bi-directional data channel between two processes on the same machine

Created with: int pipe (int fildes[2])

Read and write like files

Remote Procedure Call (RPC)

Problem which needs > 1 independent sequential process?

Some problems are hard to solve as a single sequential process; easier to express the solution as a collection of cooperating processes Hard to write code to manage many different tasks all at once How would you write code for “make phone calls while making

dinner while doing dishes while looking through the mail” Can’t be independent processes because share data (your

brain) and share resources (the kitchen and the phone) Can’t do them sequentially because need to make progress on

all tasks at once Easier to write “algorithm” for each and when there is a lull in

one activity let the OS switch between them On a multiprocessor, exploit parallelism in problem

Example: Web Server

Web servers listen on an incoming socket for requests Once it receives a request, it ignores listening to the

incoming socket while it services the request Must do both at once

One solution: Create a child process to handle the request and allow the parent to return to listening for incoming requests

Problem: This is inefficient because of the address space creation (and memory usage) and PCB initialization

Observation

There are similarities in the process that are spawned off to handle requests They share the same code, have the same

privileges, share the same resources (html files to return, cgi script to run, database to search, etc.)

But there are differences Operating on different requests Each one will be in a different stage of the “handle

request” algorithm

Idea

Let these tasks share the address space, privileges and resources

Give each their own registers (like the PC), their own stack etc

Process – unit of resource allocation (address space, privileges, resources)

Thread – unit of execution (PC, stack, local variables)

Single-Threaded vs Multithreaded Processes

Process vs Thread

Each thread belongs to one process One process may contain multiple threads Threads are logical unit of scheduling Processes are the logical unit of resource

allocation

Address Space Map For Single-Threaded Process

Stack(Space for local variables etc.

For each nested procedure call)

Heap(Space for memory dynamically

allocated e.g. with malloc)

Statically declared variables (Global variables)

Code(Text Segment)

Stack Pointer

PC

Ox0000

BiggestVirtual Address

Address Space Map For Multithreaded Process

Heap(Space for memory dynamically

allocated e.g. with malloc)

Statically declared variables (Global variables)

Code(Text Segment)

Thread 1 stackSP (thread 1)

PC (thread 2)

Ox0000

BiggestVirtual Address

PC (thread 1)

Thread 2 stackSP (thread 2)

Kernel support for threads? Some OSes support the notion of multiple threads per

process and others do not Even if no “kernel threads” can build threads at user

level Each “multi-threaded” program gets a single kernel in the

process During its timeslice, it runs code from its various threads User-level thread package schedules threads on the kernel

level process much like OS schedules processes on the CPU SAT question? CPU is to OS is to processes like? Kernel thread is to User-level thread package is to user

threads User-level thread switch must be programmed in assembly

(restore of values to registers, etc.)

User-level Threads

User-level threads

How do user level thread packages avoid having one thread monopolize the processes time slice? Solve much like OS does

Solution 1: Non-preemptive Rely on each thread to periodically yield Yield would call the scheduling function of the library

Solution 2: OS is to user level thread package like hardware is to OS Ask OS to deliver a periodic timer signal Use that to gain control and switch the running thread

Kernel vs User Threads

One might think that kernel level threads are best, and only if the kernel does not support threads should you use user level threads

In fact, user level threads can be much faster Thread creation , “Context switch” between

threads, communication between threads all done at user level

Procedure calls instead of system calls (verification of all user arguments, etc.) in all these cases!

Problems with User-level threads

OS does not have information about thread activity and can make bad scheduling decisions

Examples: If thread blocks, whole process blocks

Kernel threads can overlap I/O and computation within a process!

Kernel may schedule a process with all idle threads

Scheduler Activations

If kernel level thread support is available, then use both kernel threads *and* user-level threads

Each process requests a number of kernel threads to use for running user-level threads on

Kernel promises to tell user-level before it blocks a kernel thread so user-level thread package can choose what to do with the remaining kernel level threads

User level promises to tell kernel when it no longer needs a given kernel level thread

Thread Support

Pthreads is a user-level thread library Can use multiple kernel threads to implement it on platforms

that have kernel threads Java threads (extend Thread class) run by the Java

Virtual Machine Kernel threads

Linux has kernel threads (each has its own task_struct), created with clone system call

Each user level thread maps to a single kernel thread (Windows 95/98/NT/2000/XP, OS/2)

Many user level threads can map onto many kernel level threads like scheduler activations (Windows NT/2000 with ThreadFiber package, Solaris 2)

Pthreads Interface

POSIX threads, user-level library supported on most UNIX platforms

Much like the similarly named process functions thread = pthread_create(procedure) pthread_exit pthread_wait(thread)

Note: To use pthreads library, #include <pthread.h>

compile with -lpthread

Pthreads Interface (cont.)

Pthreads support a variety of functions for thread synchronization/coordination Used for coordination of threads (ITC) – more on this

soon!

Examples: Condition Variable(pthread_cond_wait, pthread_signal) Mutex(pthread_mutex_lock, pthread_mutex_unlock)

Performance Comparison

Processes Fork/Exit 251

Kernel Threads

Pthread_create/

Pthread_join 94

User-level

Threads

Pthread_create/

Pthread_join 4.5

In microseconds, on a 700 MHz Pentium, Linux 2.2.16, Steve Gribble, 2001.

Windows Threads

HANDLE CreateThread( LPSECURITY_ATTRIBUTES lpThreadAttributes, DWORD dwStackSize,

LPTHREAD_START_ROUTINE lpStartAddress, DWORD dwCreationFlags, LPVOID lpParameter, DWORD dwCreationFlags, LPDWORD lpThreadId);

Windows Thread Synchronization

Windows supports a variety of objects that can be used for thread synchronization

Examples Events (CreateEvent, SetEvent, ResetEvent,

WaitForSingleObject) Semaphores (CreateSemaphore, ReleaseSemaphore,

WaitForSingleObject) Mutexes (CreateMutex, ReleaseMutex,

WaitForSingleObject) WaitForMultipleObject More on this when we talk about synchronization

Warning: Threads may be hazardous to your health One can argue (and John Ousterhout did) that threads are a bad

idea for most purposes Anything you can do with threads you can do with an event loop

Remember “make phone calls while making dinner while doing dishes while looking through the mail”

Ousterhout says thread programming to hard to get right

Outtakes

Processes that just share code but do not communicate Wasteful to duplicate Other ways around this than threads

Example: User Interface

Allow one thread to respond to user input while another thread handles a long operation

Assign one thread to print your document, while allowing you to continue editing

Benefits of Concurrency

Hide latency of blocking I/O without additional complexity Without concurrency

Block whole process Manage complexity of asynchronous I/O (periodically checking

to see if it is done so can finish processing) Ability to use multiple processors to accomplish the

task Servers often use concurrency to work on multiple

requests in parallel User Interfaces often designed to allow interface to be

responsive to user input while servicing long operations

Thread pools

What they are and how they avoid thread creation overhead

Experiment

Start up various processes under Windows (Word, IE,..)

How many processes are started? How many threads and of what priority?

Scheduling CPU or “short term” scheduler selects process

from ready queue (every 10 msec or so) “dispatcher” does the process switching “long-term” scheduler controls “degree of

multiprogramming” (number of processes in memory); selects a good “job mix”

“job mix” – I/O-bound, CPU-bound, interactive, batch, high priority, background vs. foreground, real-time

“non-preemptive” (cooperative) vs. “preemptive”

Performance Measures

Throughput: #processes/time unit Turnaround time: time completed – time submitted Waiting time: sum of times spent in ready queue Response time: time from submission of a request

until the first response is produced Variation of response time (predictability)

CPU utilization Disk (or other I/O device) utilization

I/O-bound & CPU-boundDevice1

P1

CPU

P2

CPU

Device2

time quantum

I/O-bound & CPU-bound

P1: CPU-bound

Device1 idle

CPU idle CPU idle

Device1 idle Device1 idle

Turnaround time for P1

I/O-bound & CPU-bound

P2: I/O-bound

Device2 idle

CPU idle CPU idle

Device2 idle

Turnaround time for P2

I/O-bound & CPU-bound

Schedule1: non-preemptive, P1 selected first

Turnaround time for P2

Turnaround time for P1

Without P1

I/O-bound & CPU-bound

Schedule2: non-preemptive, P2 selected first

Turnaround time for P2

Turnaround time for P1

I/O-bound & CPU-bound

How does the OS know whether a process is

I/O-bound or CPU-bound?

- can monitor the behavior of a process & save the info in the PCB

- example: how much CPU time did the process use in its recent time quanta? (a small fraction => I/O intensive; all of the quantum => CPU intensive)

The nature of a typical process changes from I/O-bound to CPU-bound and back as it works through its Input/Process/Output Cycle

Preemptive vs. Non-Preemptive

t0

ready: P1, P2

t1

ready: P2blocked: P1

t2

Preemptive vs. Non-Preemptive

t3

ready: P2running: P1

t2

ready: P1blocked: P2

Non-Preemptive: must continue to run P1 at t3

Preemptive: can choose between P1 & P2 at t3

New

Ready Running

Waiting

Terminatedadmit dispatch

(4)exit,abort

(2)interrupt

(1)block for I/Oor wait for event

(3)I/O completedor event occurs

• nonpreemptive (cooperative): (1) and (4) only

• preemptive: otherwise