THREADS ADMINISTRIVIA MICHAEL ROITZSCH TU Dresden MOS Threads 2 - - PDF document

SLIDE 1

Department of Computer Science Institute for System Architecture, Operating Systems Group

THREADS

MICHAEL ROITZSCH

TU Dresden MOS – Threads

ADMINISTRIVIA

2 TU Dresden MOS – Threads

EXERCISES

3

■ due to date and room clashes we have to

divert from our regular schedule:

■ there was no exercise last week ■ there is no exercise on Oct 31st

■ moved to Nov 7th

■ there is no exercise tomorrow

■ alternative 1: this Friday, 1.00 PM, INF E06 ■ alternative 2: postpone and reorder

TU Dresden MOS – Threads

ALTERNATIVE 2

■ Nov 7th: practical „getting started“

exercise (room will be announced)

■ Nov 14th: Brinch-Hansen paper reading ■ Nov 28th: paper reading ■ Dec 5th: practical exercise „IPC“ ■ Dec 12th: paper reading ■ Jan 9th: practical exercise „Bastei“ ■ Jan 23rd: paper reading

4 TU Dresden MOS – Threads

PAPER READING

■ read the paper for the exercise:

Per Brinch-Hansen: The nucleus of a multiprogramming system

■ you find the link on the course website ■ understand it ■ be prepared to summarize it ■ be prepared to discuss it

5 TU Dresden MOS – Threads

RECAP

6

SLIDE 2

TU Dresden MOS – Threads

MICROKERNEL

7

■ kernel:

■ provides system foundation ■ usually runs in privileged CPU mode

■ microkernel:

■ kernel provides mechanisms, no policies ■ most functionality implemented in user

mode, unless dictated otherwise by ■ security ■ performance

TU Dresden MOS – Threads

ABSTRACTIONS

8

Resource Mechanism CPU Thread Memory T ask

Communication

IPC Platform

Virtual Machine

TU Dresden MOS – Threads

VIRTUAL MACHINE

9

■ provides an exclusive instance of a full

system platform

■ may be a synthetic platform (bytecode) ■ full software implementations ■ hardware-assisted implementations in the

kernel (hypervisor)

■ see virtualization lecture on Dec 11th

TU Dresden MOS – Threads

IPC

■ inter-process communication ■ between threads ■ two-way agreement, synchronous ■ short IPC: register only ■ long IPC: direct and indirect ■ memory mapping with flexpages ■ see communication lecture on Nov 6th

10 TU Dresden MOS – Threads

TASK

■ (virtual) address space ■ unit of memory management ■ provides spatial isolation ■ common memory content can be shared

■ shared libraries ■ kernel

■ see memory lecture next week

11 TU Dresden MOS – Threads

ALTERNATIVES

12

user shared system privileged Monolith Exokernel Microkernel Software Isolation 4G

SLIDE 3

TU Dresden MOS – Threads

THREADS

13 TU Dresden MOS – Threads

BASICS

14

■ abstraction of code execution ■ unit of scheduling ■ provides temporal isolation ■ typically requires a stack ■ thread state:

■ instruction pointer ■ stack pointer ■ CPU registers, flags

CPU

IP SP Regs

Code

Stack

TU Dresden MOS – Threads

STACK

■ storage for function-local data

■ local variables ■ return address

■ one stack frame per function ■ grows and shrinks

dynamically

■ grows from high to low

addresses

15

Stack Frame 1 Stack Frame 2 Stack Frame 3

TU Dresden MOS – Threads

KERNEL ‘S VIEW

■ maps user-level threads to kernel-level

threads ■ usually a 1:1 mapping ■ threads can be implemented in userland

■ assigns threads to hardware ■ one kernel-level thread per logical CPU ■ with hyper-threading & multicore, we have

more than one hardware thread now

16 TU Dresden MOS – Threads

KERNEL ENTRY

17

CPU

IP SP Regs

Code

Stack

■ thread can enter

kernel:

■ voluntarily

■ system call

■ forced

■ interrupt ■ exception

TU Dresden MOS – Threads

KERNEL ENTRY

18

Stack

Code

CPU

IP SP Regs

Code

Stack

■ IP and SP point

into kernel

■ user CPU state

stored in TCB ■ old IP and SP ■ registers ■ flags ■ FPU state ■ MMX, SSE

SLIDE 4

TU Dresden MOS – Threads

TCB

■ thread control block ■ kernel object, one per thread ■ stores thread‘s state while it is not

running

■ untrusted parts can be stored in user

space ■ separation into KTCB and UTCB

19 TU Dresden MOS – Threads

KERNEL EXIT

■ once the kernel has provided its services,

it returns back to userland

■ by restoring the saved user IP and SP ■ to the same thread or a different thread ■ the old thread may be blocking now

■ waiting for some resource

■ returning to a different thread might

involve switching address spaces

20 TU Dresden MOS – Threads

SCHEDULING

21 TU Dresden MOS – Threads

BASICS

22

■ scheduling describes the decision, which

thread to run on a CPU at a given time

■ When do we schedule?

■ current thread blocks or yields ■ time quantum expired

■ How do we schedule?

■ RR, FIFO, RMS, EDF ■ based on thread priorities

TU Dresden MOS – Threads

POLICY

■ scheduling decisions are policies ■ should not be in a microkernel ■ L4 has facilities to implement scheduling

in user land ■ each thread has an associated preempter ■ kernel sends an IPC when thread blocks ■ preempter tells kernel where to switch to

■ no efficient implementation yet ■ scheduling is the only policy still in L4

23 TU Dresden MOS – Threads

QUANTA

■ a thread‘s time quantum defines the time

it owns the CPU before it is preempted

■ preemption is the process of (involuntarily)

blocking a thread in favor of another one

■ flavors of time quanta

■ time slices for round robin scheduling ■ execution time budgets for real-time

■ time quanta get replenished

24

SLIDE 5

TU Dresden MOS – Threads

L4

■ scheduling in L4 is based on thread

priorities

■ time-slice-based round robin within the

same priority level

■ kernel manages priority and timeslice as

part of the thread state

■ Fiasco has some additional real-time

scheduling

■ see scheduling lecture on Dec 4th

25 TU Dresden MOS – Threads

EXAMPLE

■ thread 1 is a high priority driver thread,

waiting for an interrupt (blocking)

■ thread 2 and 3 are ready with equal

priority

26

Thread 1 Thread 2 Thread 3

Priority

TU Dresden MOS – Threads

EXAMPLE

■ 1 hardware thread ■ threads 2 and 3 get their time slice filled ■ scheduler selects 2 to run

27

Thread 1 Thread 2 Thread 3

Priority

TU Dresden MOS – Threads

EXAMPLE

■ thread 1 becomes ready (device interrupt

arrived)

■ its time slice is filled ■ thread 2 is preempted

28

Thread 1 Thread 2 Thread 3

Priority

TU Dresden MOS – Threads

EXAMPLE

■ thread 1 blocks again (interrupt handled,

waiting for next)

■ thread 2 has time left

29

Thread 1 Thread 2 Thread 3

Priority

TU Dresden MOS – Threads

EXAMPLE

■ thread 2‘s time slice has expired ■ scheduler selects the next thread on the

same priority level (round robin)

30

Thread 1 Thread 2 Thread 3

Priority

SLIDE 6

TU Dresden MOS – Threads

SYNCHRONIZATION

31 TU Dresden MOS – Threads

BASICS

32

■ synchronization used for

■ mutual exclusion ■ producer-consumer-scenarios

■ traditional approaches that do not work

■ spinning, busy waiting ■ disabling interrupts

TU Dresden MOS – Threads

ATOMIC OPS

■ for concurrent access to data structures ■ use atomic operations to protect

manipulations

■ only suited for simple critical sections

33 TU Dresden MOS – Threads

EXPECTATION

34

Thread 1 Thread 2

T h r e a d 1 i n c r i t i c a l s e c t i

• n

T h r e a d 2 i n c r i t i c a l s e c t i

• n

TU Dresden MOS – Threads

SOLUTION

35

Thread 1 Thread 2

T h r e a d 1 i n c r i t i c a l s e c t i

• n

T h r e a d 2 i n c r i t i c a l s e c t i

• n

Serializer Thread

TU Dresden MOS – Threads

SEMAPHORES

36

■ serializer and atomic operations can be

combined to a nice counting semaphore

■ semaphore

■ shared counter for correctness ■ wait queue for fairness ■ down (P) and up (V) operation ■ semaphore available iff counter > 0

SLIDE 7

TU Dresden MOS – Threads

SEMAPHORES

■ counter increments and decrements using

atomic operations

■ when necessary, call semaphore thread to

block/unblock and enqueue/dequeue

37

Thread 1 Thread 2 Semaphore Thread

down down

enqueue and block

up

dequeue and unblock

up

TU Dresden MOS – Threads

BENEFITS

■ cross-task semaphores, when counter is

in shared memory

■ IPC only in the contention case ■ good for mutual exclusion when

contention is rare

■ for producer-consumer-scenarios,

contention is the common case

■ solution for small critical sections in

scheduling lecture

38 TU Dresden MOS – Threads

NOVA

39 TU Dresden MOS – Threads

INTRODUCTION

40

■ NOVA is a research microhypervisor

currently developed by Udo Steinberg

■ explore technologies for a small and

robust platform that hosts: ■ legacy operating systems ■ native NOVA applications

TU Dresden MOS – Threads

FEATURES

41

Mechanism L4 NOVA Thread ✔ ✔ T ask ✔ ✔ IPC ✔ ✔

Virtual Machine ✘

✔

TU Dresden MOS – Threads

KERNEL STYLES

42

Process-Style Interrupt-Style

■

• ne kernel stack per thread ■
• ne kernel stack per CPU

■

context switch: switch to stack of target thread

■

context switch: save state

• f current thread, discard

stack, restore state of target thread

■

state retained on stack at switch time

■

can switch anytime

■

state must be serializable at switch time

■

all state made explicit

■

target thread resumes at last context switch point

■

target thread resumes with empty stack in continuation function Fiasco, Linux NOVA

SLIDE 8

TU Dresden MOS – Threads

RECAP

43

■ repeated basic microkernel concepts

■ tasks, threads, IPC

■ closer look on threads

■ TCB, kernel entry

■ scheduling

■ time quantum, priorities, preemption

■ synchronization

■ atomic ops, serializer thread, semaphore

■ next up: memory management