What we will learn Multi Process Systems: Processes &Threadshomes.di.unimi.it/.../MatDidatSOD2009_files/SODLez13_MPProcessx… · Multi Process Systems: Processes &Threads Operating

Operating Systems and Distributed Systems

Multi Process Systems: Processes &Threads


What we will learn

• A thread-driven approach is attractive in sensor networks for many of the same reasons that it has been adopted for PDAs, laptops, and servers.

• In a thread-driven system, an application programmer need not be concerned about indefinitely blocking or being indefinitely blocked by other tasks during execution, except for shared resources, because the scheduler will preemptively time-slice between threads, allowing some tasks to continue execution even though others may be blocked.

• This automated time-slicing considerably simplifies programming for an application developer.


Processes (classic vs. modern)

ST OS

MT OS

MP OS

Coroutines

Threads

Processes

Bag of functions& procedures{

weak AUCs

AUCs

AUCs

(AUCs)

(AUCs)

(AUCs)


Architectural support: Processor Modes

• Mode bit: Supervisor or User mode

• Supervisor mode

– Can execute all machine instructions

– Can reference all memory locations

• User mode– Can only execute a subset of instructions

– Can only reference a subset of memory locations



Total CPU time percentage

Kernel mode time percentage



– The status register contains information about the status of features of the computer that can be set by the processor while in kernel mode

indicates whether

current status is kernel or user

indicates whether the

processor was in kernel or

user mode when the last

exception occurred


• The processor contains registers useful for handling exceptions but is not accessible in user mode. – the status register,

– cause register,

– BadVaddr, and

– EPC (exception program counter).

Architectural support: Processor Modes (MIPS)



BadVaddr 8 memory address at which address exception occurredStatus 12 interrupt mask and enable bitsCause 13 exception type and pending interruptsEPC(IAR) 14 address of instruction that caused exception

name number information



– The status register contains information about the status of features of the computer that can be set by the processor while in kernel mode

indicates whether

current status is kernel or user

indicates whether the

processor was in kernel or

user mode when the last

exception occurred

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

Mod

e

En

ab

le

Mod

e

En

ab

le

Mod

e

En

ab

le

Mode: 1=user, 0=kernel

Enable: 1=on, 0=off

Old Prev Cur


Kernels

• The part of the OS critical to correct operation (trusted software)

• Executes in supervisor mode

• The trap instruction is used to switch from user to supervisor mode, entering the OS

Operating Systems and Distributed Systems11

What happens on a trap/interrupt?

1. Hardware saves program counter (on stack or in a special register)

2. Hardware loads new PC, identifies interrupt

3. Assembly language routine saves registers

4. Assembly language routine sets up stack

5. Assembly language calls C to run service routine

6. Service routine calls scheduler

7. Scheduler selects a process to run next (might be the one interrupted…)


• OS runs in privileged mode– Some operations are permitted only in

privileged (also called supervisor or system) mode

• Example: access a device like a disk or network card

• Example: change allocation of memory to processes

– User programs run in user mode and can’t do the operations

• Programs want the OS to perform a service

What happens on a trap?


How system calls work

• User program enters supervisor mode– Must enter via well-defined entry point

• Program passes relevant information to OS• OS performs the service if

– The OS is able to do so

– The service is permitted for this program at this time

• OS checks information passed to make sure it’s OK– Don’t want programs reading data into other


• System call:Sleep()

• Program pushes arguments, calls library

• Library sets up trap, calls OS

• OS handles system call

• Control returns to library

• Library returns to user program

Return to caller

Trap to kernel

Trap code in register

Increment SP

Call Sleep

Push arguments

DispatchSys callhandler

Kernelspace(OS)

Userspace

0xffffffff

1

2

3

4

5 6

7

8

9

Library

(Sleep call)

Usercode

#include <sys/process.h >

void main(){

! ...

! Sleep();

! ...

}

extern void!Sleep (void);

process.h

;;; Stub functions for traps.

.proc _Sleep

.global _Sleep

_Sleep:!

! trap! #0x410!

! nop

! jr! r31

! nop

.endproc _Sleep

#define! TRAP_SLEEP! 0x410

traps.h

.proc _intrhandler

.global _intrhandler

_intrhandler:

........

;; push regs on stack

j! _dointerrupt!

.endproc _intrhandler

void dointerrupt (unsigned int cause,

unsigned int iar, unsigned int isr,

! uint32 *trapArgs)

{

// TRAP_INSTR bit is set: trap instruction.

// bit isn't set:system interrupt.

if (cause & TRAP_TRAP_INSTR) {

.....

switch (cause) {

case TRAP_SLEEP:

Suspend (currentPCB);

Schedule ();

break;

.....

intrreturn ();

}

.proc! _intrreturn

! .global!_intrreturn

_intrreturn:

! ;; Disable interrupts

....;; Reload the regs for new process.

.endproc _intrreturnOperating Systems and Distributed Systems

CAUSE registerSTATUS register


Supervisor and User Memory

UserSpace

SupervisorSpace

UserProcess

SupervisorProcess


Threads, Processes, Modern Processes

Thread

Process Process

Thread

Process

ThreadThread

Thread


OS Address

Space

Implementing the Process Abstraction

Control

Unit

OS interface

…

Mac

hin

e E

xec

uta

ble

Mem

ory

ALU

CPUPi Address

Space

Pi CPU

Pi Executable

Memory

Pk Address

Space

…

Pk CPU

Pk Executable

Memory

Pj Address

Space

Pj CPU

Pj Executable

Memory


What’s in a process?

• A process consists of (at least):– an address space

– the code for the running program

– the data for the running program

– an execution stack and stack pointer (SP)• traces state of procedure calls made

– the program counter (PC), indicating the next instruction

– general-purpose processor registers and their values


0x00000000

0xFFFFFFFF

address space

code

(text segment)

static data

(data segment)

heap

(dynamic allocated mem)

stack


PC

SP

The Process Address Space


The Process Address Space

Process

Address

Space

Address

Binding

Executable

Memory

Other objects

Files


Building the Address Space

• Some parts are built into the environment– Files

– System services

• Some parts are imported at runtime– Mailboxes

– Network connections

• Memory addresses are created at compile (and run) time


Process Manager Overview

Program Process

Abstract Computing Environment

FileManager

MemoryManager

DeviceManager

Protection

Deadlock

Synchronization

ProcessDescription

CPU Other H/W

SchedulerResourceManagerResourceManagerResourceManager

MemoryDevices


UNIX Organization

System Call Interface

FileManager

MemoryManager

DeviceManager

Protection

Deadlock

Synchronization

ProcessDescription

CPU Other H/W

SchedulerResourceManagerResourceManagerResourceManager

MemoryDevices

LibrariesProcess

Process

Process

Monolithic Kernel


Windows NT Organization

Processor(s) Main Memory Devices

Libraries

Process

Process

Process

SubsystemUser

Subsystem Subsystem

Hardware Abstraction Layer

NT Kernel

NT Executive

I/O Subsystem

TT

T

T

TT T T

T


External View of the Process Manager

Hardware

Application

Program

Dev

ice

Mgr

Pro

cess

Mgr

Mem

ory

Mgr

Fil

e M

gr

UNIX

Dev

ice

Mgr

Pro

cess

Mgr

Mem

ory

Mgr

Fil

e M

gr

Windows

CreateThread()CreateProcess()

CloseHandle()

WaitForSingleObject()

fork()

exec()wait()


Process Manager Responsibilities

• Define & implement the essential characteristics of a process and thread– Algorithms to define the behavior– Data structures to preserve the state of the execution

• Define what “things” threads in the process can reference – the address space (most of the “things” are memory locations)

• Manage the resources used by the processes/threads• Tools to create/destroy/manipulate processes & threads• Tools to time-multiplex the CPU – Scheduling • Tools to allow threads to synchronization the operation

with one another • Mechanisms to handle deadlock • Mechanisms to handle protection


The Abstract Machine Interface

User ModeInstructions

Application Program

User Mode

Instructions

Abstract Machine Instructions

Trap

Instruction

Supervisor ModeInstructions

fork()

create()open()

OS


Tracing the Hardware Process

Bootstap

Loader

Process

ManagerInterrupt

Handler P1 P,2 Pn

…

Machine is

Powered up

Initialization

Load the kernel

Service an interrupt

Har

dw

are

pro

cess

pro

gre

ss

Execute a thread

Schedule


Context Switching

Process

Manager

Interrupt

Handler

P1

P2

Pn

Executable Memory

Initialization1

23

4

5

7Interrupt

8

9

6

12/31/2006 © 2007 Gribble, Lazowska, Levy, Zahorjan 31

• There’s a data structure called the process control block (PCB) that holds all this stuff– The PCB is identified by an integer process ID (PID)

• OS keeps all of a process’s hardware execution state in the PCB when the process isn’t running

– PC, SP, registers, etc.

– when a process is unscheduled, the state is transferred out of the hardware into the PCB

• Note: It’s natural to think that there must be some esoteric techniques being used– fancy data structures that’d you’d never think of yourself

Wrong! It’s pretty much just what you’d think of!

Process Descriptors


This is (a simplification of)

what each of those PCBs looks

like inside!

Process ID

Pointer to parent

List of children

Process state

Pointer to address space descriptor

Program countstack pointer

(all) register values

uid (user id)

gid (group id)

euid (effective user id)

Open file list

Scheduling priority

Accounting info

Pointers for state queues

Exit (“return”) code value

Process Descriptors


What’s in a process table entry?

File managementRoot directory

Working (current) directory

File descriptors

User ID

Group ID

Memory managementPointers to text, data, stack

! or

Pointer to page table

Process managementRegisters

Program counter

CPU status word

Stack pointer

Process state

Priority / scheduling parameters

Process ID

Parent process ID

Signals

Process start time

Total CPU usage

May be

stored

on stack


Unix Process Descriptor


Linux Process Descriptor


EPROCESS

…

void *UniqueProcessId;

…

NT Executive

Windows NT Process Descriptor

KPROCESS…

uint32 KernelTime;

uint32 UserTime;

…

Byte state;

NT Kernel


ETHREAD

Windows NT Thread Descriptor

EPROCESS

KPROCESS

NT Kernel

KTHREAD

NT Executive


When is a process created?• Processes can be created in two ways

– System initialization (creatio ex nihilo): one or more processes created when the OS starts up

– Execution of a process creation system call: something explicitly asks for a new process

• System calls can come from– User request to create a new process (system

call executed from user shell)

– Already running processes• User programs

• System daemons


Creating a Process in UNIX

pid = fork();

UNIX kernel

…

Process Table

Process Descriptor


Creating a Process in NT

CreateProcess(…);

Win32 Subsystem

ntCreateProcess(…);

…

ntCreateThread(…);

NT Executive

NT Kernel

…

Handle Table

Process Descriptor


Windows NT Handles


Process states• Each process has an execution state, which

indicates what it is currently doing– ready: waiting to be assigned to CPU

• could run, but another process has the CPU

– running: executing on the CPU• is the process that currently controls the CPU

• pop quiz: how many processes can be running simultaneously?

– waiting: waiting for an event, e.g., I/O• cannot make progress until event happens


Simple State Diagram

ReadyBlocked

Running

Start

Request

Done

exception (I/O, page fault, etc.)

interrupt (unschedule)

dispatch / schedule

interrupt(I/O complete)


The PCB revisited (Unix)

• The PCB is a data structure with many, many fields:

– process ID (PID)

– execution state

– program counter, stack pointer, registers

– address space info

– UNIX username of owner

– scheduling priority

– accounting info

– pointers for state queues

• In linux:

– defined in task_struct (include/linux/sched.h)

– over 95 fields!!!


Blocked

(waiting)

Created

Exit

Ready

Running

Refined state model

! Process in one of 5 states

" Created

" Ready

" Running

" Blocked

" Exit

! Transitions between states

1. Process enters ready queue

2. Scheduler picks this process

3. Scheduler picks a different process

4. Process waits for event (such as I/O)

5. Event occurs

6. Process exits

7. Process ended by another process

1

5

4

3

2

7

76


Linux State Transition Diagram

Runnable

UninterruptibleSleep

Running

Start

Schedule

Request

Done

I/O Request

Allocate

zombie

Wait by

parent

Sleeping

Traced or Stopped

Request

I/O Complete Resume

TASK_INTERRUPTIBLE The process is suspended (sleeping) until some condition becomes true. Raising a hardware interrupt, releasing a system

resource the process is waiting for, or delivering a signal are examples of conditions that might wake up the process (put its state back to

TASK_RUNNING).

TASK_UNINTERRUPTIBLE Like TASK_INTERRUPTIBLE, except that delivering a signal to the sleeping process leaves its state unchanged. This process

state is seldom used. It is valuable, however, under certain specific conditions in which a process must wait until a given event occurs without

being interrupted. For instance, this state may be used when a process opens a device file and the corresponding device driver starts probing

for a corresponding hardware device. The device driver must not be interrupted until the probing is complete, or the hardware device could be

left in an unpredictable state.

TASK_STOPPED Process execution has been stopped; the process enters this state after receiving a SIGSTOP, SIGTSTP, SIGTTIN, or SIGTTOU signal.

TASK_TRACED Process execution has been stopped by a debugger. When a process is being monitored by another (such as when a debugger

executes a ptrace( ) system call to monitor a test program), each signal may put the process in the TASK_TRACED state.

Two additional states of the process can be stored both in the state field and in the exit_state field of the process descriptor; as the field

name suggests, a process reaches one of these two states only when its execution is terminated:

EXIT_ZOMBIE Process execution is terminated, but the parent process has not yet issued a wait4( ) or waitpid( ) system call to return

information about the dead process.[*] Before the wait( )-like call is issued, the kernel cannot discard the data contained in the dead process

descriptor because the parent might need it. (See the section "Process Removal" near the end of this chapter.)

[*] There are other wait( ) -like library functions, such as wait3( ) and wait( ), but in Linux they are implemented by means of the wait4( ) and

waitpid( ) system calls.

EXIT_DEAD The final state: the process is being removed by the system because the parent process has just issued a wait4( ) or waitpid( )

system call for it. Changing its state from EXIT_ZOMBIE to EXIT_DEAD avoids race conditions due to other threads of execution that execute

wait( )-like calls on the same process (see Chapter 5).

The value of the state field is usually set with a simple assignment. For instance:

p->state = TASK_RUNNING;


Linux State Transition Diagram


Windows NT Thread States

Initialized

CreateThread

Ready

Activate

Sel

ect

Standby

Running

Terminated

Waiting

Transition

Reinitialize

Exit

Pre

empt

Dispatch

Wait

Wait Complete

Wait Complete

Dispatch


Modern processes: concurrency• Imagine a web server, which might like to handle multiple requests

concurrently

– While waiting for the credit card server to approve a purchase for one client, it could be retrieving the data requested by another client from disk, and assembling the response for a third client from cached information

• Imagine a web client (browser), which might like to initiate multiple requests concurrently

– The CSE home page has 46 “src= …” html commands, each of which is going to involve a lot of sitting around! Wouldn’t it be nice to be able to launch these requests concurrently?

• Imagine a parallel program running on a multiprocessor, which might like to employ “physical concurrency”

– For example, multiplying a large matrix – split the output matrix into k regions and compute the entries in each region concurrently using k processors


• In each of these examples of concurrency (web server, web client, parallel program):– Everybody wants to run the same code

– Everybody wants to access the same data

– Everybody has the same privileges

– Everybody uses the same resources (open files, network connections, etc.)

• But you’d like to have multiple hardware execution states:– an execution stack and stack pointer (SP)

• traces state of procedure calls made

– the program counter (PC), indicating the next instruction

– a set of general-purpose processor registers and their values

Modern processes: concurrency


• Given the process abstraction as we know it:

– fork several processes

– cause each to map to the same physical memory to share data

• see the shmget() system call for one way to do this (kind of)

• This is like making a pig fly – it’s really inefficient

– space: PCB, page tables, etc.

– time: creating OS structures, fork and copy addr space, etc.

• Some equally bad alternatives for some of the examples:

– Entirely separate web servers

– Manually programmed asynchronous programming (non-blocking I/O) in the web client (browser)

Modern processes: concurrency


Can we do better?

• Key idea:– separate the concept of a process (address

space, etc.)

– …from that of a minimal “thread of control” (execution state: PC, etc.)

• This execution state is usually called a thread, or sometimes, a lightweight process


Modern Processes and Threads

OS interface

…

…

…

Pi CPU

Thrdj in Pi Thrdk in Pi

…


Single and Multithreaded Processes


Kernel Kernel

ThreadsThreadsSystem

space

User

space

Process 1 Process 2 Process 3 Process 1

Threads: “processes” sharing memory• Process == address space

• Thread == program counter / stream of instructions

• Two examples

– Three processes, each with one thread

– One process with three threads


Process & thread information

Per process itemsAddress space

Open files

Child processes

Signals & handlers

Accounting info

Global variables

Per thread itemsProgram counter

Registers

Stack & stack pointer

State


Registers


State


Registers


State


Threads & stacks

Kernel

Process

Thread 1 Thread 2 Thread 3

Thread 1"s

stack

Thread 3"s

stack

Thread 2"s

stack

User space

=> Each thread has its own stack!


Multithreaded Web server

Kernel

Network

connection

Dispatcherthread

Workerthread

Web pagecache

while(TRUE) {

getNextRequest(&buf);

handoffWork(&buf);

}

while(TRUE) {

waitForWork(&buf);

lookForPageInCache(&buf,&page);

if(pageNotInCache(&page)) {

readPageFromDisk(&buf,&page);

}

returnPage(&page);

}


Threads and processes

• Most modern OS’s (Mach, Chorus, NT, modern UNIX) therefore support two entities:– the process, which defines the address space and general process

attributes (such as open files, etc.)

– the thread, which defines a sequential execution stream within a process

• A thread is bound to a single process / address space– address spaces, however, can have multiple threads executing

within them

– sharing data between threads is cheap: all see the same address space

– creating threads is cheap too!

• Threads become the unit of scheduling– processes / address spaces are just containers in which threads

execute


The design space

address space

thread

one thread/process

many processes

many threads/process

many processes

one thread/process

one process


one process

MS/DOS

Java

older

UNIXes

Mach, NT,

Chorus,

Linux, …

Key


(old) Process address space

0x00000000

0xFFFFFFFF

address space

code

(text segment)

static data

(data segment)

heap


stack


PC

SP


(new) Process address space with threads

0x00000000

0xFFFFFFFF

address space

code

(text segment)

static data

(data segment)

heap


thread 1 stack

PC (T2)

SP (T2)

thread 2 stack

thread 3 stack

SP (T1)

SP (T3)

PC (T1)

PC (T3)


Process/thread separation: advantages

• Concurrency (multithreading) is useful for:

– handling concurrent events (e.g., web servers and clients)

– building parallel programs (e.g., matrix multiply, ray tracing)

– improving program structure (the Java argument)

• Multithreading is useful even on a uniprocessor

– even though only one thread can run at a time

• Supporting multithreading – that is, separating the concept of a process (address space, files, etc.) from that of a minimal thread of control (execution state), is a big win

– creating concurrency does not require creating new processes

– “faster / better / cheaper”


“Where do threads come from?”

• Natural answer: the kernel is responsible for creating/managing threads– for example, the kernel call to create a new

thread would• allocate an execution stack within the process

address space

• create and initialize a Thread Control Block– stack pointer, program counter, register values

• stick it on the ready queue

– we call these kernel threads


• Threads can also be managed at the user level (that is, entirely from within the process)

– a library linked into the program manages the threads

• because threads share the same address space, the thread manager doesn’t need to manipulate address spaces (which only the kernel can do)

• threads differ (roughly) only in hardware contexts (PC, SP, registers), which can be manipulated by user-level code

• the thread package multiplexes user-level threads on top of kernel thread(s), which it treats as “virtual processors”

– we call these user-level threads

“Where do threads come from?” (2)


Implementing threads

Kernel

Run-timesystem

Threadtable

Processtable

Kernel

Thread

Process

Threadtable

Processtable

User-level threads

+ No need for kernel support

- May be slower than kernel threads

- Harder to do non-blocking I/O

Kernel-level threads

+ More flexible scheduling

+ Non-blocking I/O

- Not portable


Kernel Threads

• Supported by the Kernel

• Examples

– Windows XP/2000

– Solaris

– Linux

– Tru64 UNIX

– Mac OS X


User Threads

• Thread management done by user-level threads library

• Three primary thread libraries:

– POSIX Pthreads

– Win32 threads

– Java threads


Kernel threads

• OS now manages threads and processes– all thread operations implemented in the kernel

– OS schedules all of the threads in a system• one thread in a process blocks ( I/O): the OS knows about it, and can run

other threads from that process

• possible to overlap I/O and computation inside a process

• Kernel threads are cheaper than processes– less state to allocate and initialize

• Still pretty expensive for fine-grained use (e.g., orders of magnitude more expensive than a procedure call)– thread operations are all system calls

• context switch

• argument checks

– must maintain kernel state for each thread


User-level threads• To make threads cheap and fast, they need to be implemented

at the user level

– managed entirely by user-level library, e.g., libpthreads.a

– The thread package multiplexes user-level threads on top of kernel thread(s), which it treats as “virtual processors”

• User-level threads are small and fast

– each thread is represented simply by

• PC & registers,

• stack,

• small thread control block (TCB)

– creating a thread, switching between threads, and synchronizing threads are done via procedure calls

• no kernel involvement is necessary!

– user-level thread operations can be 10-100x faster than kernel threads as a result


Performance example

• On a 700MHz Pentium running Linux 2.2.16:

– Processes• fork/exit: 251 µs

– Kernel threads• pthread_create()/pthread_join(): 94 µs (2.5x faster)

– User-level threads• pthread_create()/pthread_join: 4.5 µs (another 20x

faster)


Performance example (2)

• On a 700MHz Pentium running Linux 2.2.16:

• On a DEC SRC Firefly running Ultrix, 1989

– Processes

• fork/exit: 251 µs / 11,300 µs

– Kernel threads• pthread_create()/pthread_join(): 94 µs / 948 µs (12x faster)

– User-level threads• pthread_create()/pthread_join: 4.5 µs / 34 µs (another 28x

faster)


The design space

address space

thread

one thread/process

many processes


many processes

one thread/process

one process


one process

MS/DOS

Java

older

UNIXes

Mach, NT,

Chorus,

Linux, …


address space

thread

Mach, NT,

Chorus,

Linux, …

os kernel

(thread create, destroy, signal, wait, etc.)

CPU

Kernel thread implementation


address space

thread

Mach, NT,

Chorus,

Linux, …

os kernel

CPU

User-level threads: conceptuallyuser-level

thread library


?


address space

thread

Mach, NT,

Chorus,

Linux, …

os kernel

(kernel thread create, destroy, signal, wait, etc.)

CPU

User-level threads: implementeduser-level

thread library


kernel threads


address space

thread

Mach, NT,

Chorus,

Linux, …

os kernel

user-levelthread library


(kernel thread create, destroy, signal, wait, etc.)

CPU

kernel threads

User-level threads: implemented


Multithreading Models

• Many-to-One

• One-to-One

• Many-to-Many


Many-to-One

• Many user-level threads mapped to single kernel thread

• Examples:– Solaris Green Threads

– GNU Portable Threads


Many-to-One Model


One-to-One

• Each user-level thread maps to kernel thread

• Examples– Windows NT/XP/2000

– Linux

– Solaris 9 and later


One-to-one Model


Many-to-Many Model

• Allows many user level threads to be mapped to many kernel threads

• Allows the operating system to create a sufficient number of kernel threads

• Solaris prior to version 9

• Windows NT/2000 with the ThreadFiber package


Many-to-Many Model


Two-level Model

• Similar to M:M, except that it allows a user thread to be bound to kernel thread

• Examples– IRIX

– HP-UX

– Tru64 UNIX

– Solaris 8 and earlier


Two-level Model


User-level thread implementation

• The kernel believes the user-level process is just a normal process running code

– But, this code includes the thread support library + its associated thread scheduler

• The thread scheduler determines when a thread runs

– it uses queues to keep track of what threads are doing: run, ready, wait

• just like the OS and processes

• but, implemented at user-level as a library


• Strategy 1: force everyone to cooperate– a thread willingly gives up the CPU by calling yield()

– yield() calls into the scheduler, which context switches to another ready thread

– what happens if a thread never calls yield()?

• Strategy 2: use preemption– scheduler requests that a timer interrupt be delivered by

the OS periodically• usually delivered as a UNIX signal (man signal)

• signals are just like software interrupts, but delivered to user-level by the OS instead of delivered to OS by hardware

– at each timer interrupt, scheduler gains control and context switches as appropriate

How to keep a user-level thread fromhogging the CPU?


Thread context switch• Very simple for user-level threads:

– save context of currently running thread• push machine state onto thread stack

– restore context of the next thread• pop machine state from next thread’s stack

– return as the new thread

• execution resumes at PC of next thread

• This is all done by assembly language

– it works at the level of the procedure calling convention

• thus, it cannot be implemented using procedure calls

• e.g., a thread might be preempted (and then resumed) in the middle of a procedure call


What if a thread tries to do I/O?

• The kernel thread “powering” it is lost for the duration of the (synchronous) I/O operation!

– Could have one kernel thread “powering” each user-level thread

• no real difference from kernel threads – “common case” operations (e.g., synchronization) would be quick

– Could have a limited-size “pool” of kernel threads “powering” all the user-level threads in the address space

• the kernel will be scheduling these threads, obliviously to what’s going on at user-level


What if the kernel preempts a threadholding a lock?

• Other threads will be unable to enter the critical section and will block (stall)

– tradeoff, as with everything else

• Solving this requires coordination between the kernel and the user-level thread manager

– Possible solution: “scheduler activations”• each process can request one or more kernel threads

– process is given responsibility for mapping user-level threads onto kernel threads

– kernel promises to notify user-level before it suspends or destroys a kernel thread


Summary

Documents

What we will learn Multi Process Systems: Processes &Threadshomes.di.unimi.it/.../MatDidatSOD2009_files/SODLez13_MPProcessx… · Multi Process Systems: Processes &Threads Operating