Threads David Ferry CSCI 3500 – Operating Systems Saint Louis University St. Louis, MO 63103
CSCI 3500 - Operating Systems Processes vs. Threads Process – a program in execution Every process has at least one thread Comprehensive abstraction for execution Tracks memory usage, files opened, etc. Thread – an execution context A processor state (register file and program counter) plus a stack Everything needed for the fetch, decode, execute cycle Belong to a specific process, share resources May have many threads per process Lighter weight and faster to create/deploy/destroy CSCI 3500 - Operating Systems
CSCI 3500 - Operating Systems Single Thread Model Process Control Block (PCB) .stack Memory Map Open Files Accounting Info Program Counter Register File Etc. .heap .data .text CSCI 3500 - Operating Systems
Multiple Threads Model Process Control Block (PCB) .stack Memory Map Open Files Accounting Info Program Counter Register File Etc. .stack .stack .heap .data .text Register file contains stack pointers. Creating a thread does not need new PCB CSCI 3500 - Operating Systems
CSCI 3500 - Operating Systems Why use threads? In parallel computing the goal is to accelerate computations Split one large piece of work across multiple threads, and execute on multiple processors In concurrent programming threads provide: Separation of concerns Latency hiding for blocking I/O CSCI 3500 - Operating Systems
Concurrency: Separation of Concerns Sequential computing often introduces accidental complexity – unintended interactions between different program elements. main(){ functionA(); functionB(); functionC(); } If functions A, B, and C do not interact with one another, then their sequential dependence is accidental. If functionB() hangs, then functionC() is impacted. CSCI 3500 - Operating Systems
Concurrency: Separation of Concerns Consider a simple game structure: while(1){ play_sound(); do_physics(); draw_graphics(); } A bug or hang in any of these functions impacts the others. Suppose a sound or image loads slowly from disk Putting each of these in a thread allows each to progress at their own rate. Behavior of the overall program is decoupled from the progress of any individual part. Adds complexity where these pieces interact CSCI 3500 - Operating Systems
Concurrency: Hiding I/O and Blocking Latency Suppose we have two independent but I/O-heavy compute routines: main(){ computeA(); computeB(); } Calls such as file access may take a while to complete, or may block entirely. In the above structure all such delays contribute to program runtime. If these functions are threaded then one can execute while the other is blocked. Even if we only have one physical processor. CSCI 3500 - Operating Systems
Early Threading Success: Web Servers Studies show internet users are impatient. A goal of web companies is to minimize the time it takes to get your page. Suppose you are a web search provider, and some searches are fast (e.g. cached), while other searches are slow. How do we minimize latency for fast requests? Request Queue (First-In, First-Out) Web Server CSCI 3500 - Operating Systems
Multithreaded Web Server Suppose the web server has a team of threads that it switches between rapidly (i.e. multiprogramming). Slow requests take longer Fast requests much less likely to get stuck after a slow request Works even if we only have one processor. Web Server Request Queue (First-In, First-Out) CSCI 3500 - Operating Systems
CSCI 3500 - Operating Systems pthreads Interface pthreads (POSIX threads) is a cross-platform library for threading and thread management. Very much a C-style interface- no OOP so no thread objects. No type polymorphism, instead we use void* (typeless) pointers and it’s up to the programmer to ensure correctness. Uses a function pointer to determine where thread starts executing. pthread_create( pthread_t*, NULL, (void*)*(void*), void*) pthread_join( pthread_t, void**) See documentation/studios/examples for details… CSCI 3500 - Operating Systems