1 / 17

Threads

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.

dena
Télécharger la présentation

Threads

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Threads • math 442 es • Jim Fix

  2. 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

  3. 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 application pgm la la land libraries OS CPU memory I/O the real deal

  4. 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

  5. A Unix Process hi stack execution state • Recall our depiction of a process: CC RegF heap SP .bss PC .data lo .text file descriptors,scheduler info,... address space OS info see http://www.nongnu.org/avr-libc/user-manual/malloc.html

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

  7. 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?)

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

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

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

  11. 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.

  12. 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)

  13. 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”

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

  15. 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.

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

  17. POSIX threads • Standardized pthread library routines (actually, several) for: • creation/joining • setting attributes • mutual exclusion • software condition (queues) • see https://computing.llnl.gov/tutorials/pthreads/

More Related