Threads math 442 es Jim Fix

Reality vs. Abstraction A computer’s OS manages a lot: multiple users many devices; hardware interrupts multiple application programs multiple processors/cores... but a modern OS presents a different reality to application programmers

API Layers Most APIs’ (Application’s Programming Interfaces’) goal is to abstract away the underlying HW/SW system details. ``file”, ``socket’’, ``address”, ``lock”,... libraries form this abstraction layer CPU I/O memory OS application pgm libraries la la land the real deal

Example: Unix ``process” abstraction of what is associated with execution of a program two major components: a ``thread” of control (execution state) address space (execution context) gives the illusion that a program has exclusive access to a single machine

A Unix Process Recall our depiction of a process:.data stack heap.text.bss address space hi execution state lo RegF SP PC CC file descriptors, scheduler info,... OS info see

Why not......have multiple threads of control?.data heap.bss hi TCB 1 lo RegF SP PC CC file descriptors, scheduler info,... OS info TCB 2 RegF SP PC CC.text TCB = thread control block

Thread / “lightweight process” Let’s decouple ``address space” & ``thread”? Allow multiple threads to share an address space and OS context Give the illusion of having multiple processors (Why is this useful?)

Example use of threads: In a web browser: one thread renders a page while another fetches data and another displays a media stream &c

Example use of threads: In a web server: ``master” thread that fields requests ``worker” threads that handle requests script execution (remote) database access &c

Example use of threads: Embedded/control systems are naturally multithreaded airplane navigation medical equipment factory control > many system components; somewhat independent.

Benefits: code structure Code might naturally......manage multiple tasks: e.g. web browser; emb’d sys.; evil dwg robot...handle concurrent/asynchronous events e.g., server; r-t sys.; videogame; evil dwg robot...have lots of (data) parallelism e.g., raytracer; videogame; 100 evil dwg robots, centrally controlled > many system components; somewhat independent.

Benefits: performance I/O op may be blocking waiting for data; can do other useful work faster response time; requests don’t get queued up may actually execute on different processor cores (true concurrency) different physical resources can be used simultaneously (true parallelism)

Perf. Gains multi-process vs. multi-thread overhead: process creation and all that it entails (process ``fork”: new VM mgmt, address space copy) overhead of inter-process communication (IPC) overhead of system calls ``heavyweight” threads are sometimes called ``lightweight processes”

Perf. Gains (see H. Levy’s data) (see LLNL’s data)

Issues (C) thread library API? thread library implementation? who’s responsible for managing threads? (Kernel vs. User-level) (>C) language abstraction? Also... It’s just a fact: writing multi-threaded programs is hard.

Reading ``THE microprogramming system”, ``THE microprogramming system”, (Dijkstra, 1968) ``Prgmg w/ Threads” (Birrel, 1989) ``POSIX threads” (LLNL,2008)

POSIX threads Standardized pthread library routines (actually, several) for: creation/joining setting attributes mutual exclusion software condition (queues) see