CS 332 s20 — Thread API and Implementation

• thread API analogous to asynchronous procedure call
• thread_create is similar to fork / exec, thread_join is similar to wait

#include <stdio.h>
#include "thread.h"

static void go(int n);

#define NTHREADS 10
static thread_t threads[NTHREADS];

int main(int argc, char **argv) {
    int i;
    long exitValue;

    for (i = 0; i < NTHREADS; i++){
        thread_create(&(threads[i]), &go, i);
    }
    for (i = 0; i < NTHREADS; i++){
        exitValue = thread_join(threads[i]);
        printf("Thread %d returned with %ld\n", 
                        i, exitValue);
    }
    printf("Main thread done.\n");
    return 0;
}

void go(int n) {
    printf("Hello from thread %d\n", n);
    thread_exit(100 + n);
    // Not reached
}

• thread_t is a struct with thread-specific metadata
• the second argument, go is a function pointer—where the newly created thread show begin execution
• the third argument, i, is passed to the function

$ ./threadHello
Hello from thread 0
Hello from thread 1
Thread 0 returned 100
Hello from thread 3
Hello from thread 4
Thread 1 returned 101
Hello from thread 5
Hello from thread 2
Hello from thread 6
Hello from thread 8
Hello from thread 7
Hello from thread 9
Thread 2 returned 102
Thread 3 returned 103
Thread 4 returned 104
Thread 5 returned 105
Thread 6 returned 106
Thread 7 returned 107
Thread 8 returned 108
Thread 9 returned 109

• why might the "Hello" message from thread 2 print after the "Hello" message from thread 5, even though thread 2 was created before thread 5?
  • creating and scheduling are separate operations: only assumption is that threads run on their own virtual processor with unpredictable speed, any interleaving is possible
• why must the "Thread returned" message from thread 2 print before the Thread returned message from thread 5?
  • the threads can finish in any order, but the main thread waits for them in the order they were created
• what is the minimum and maximum number of threads that could exist when thread 5 prints "Hello"?
  • minimum is 2 threads: thread 5 and the main thread
  • maximum is 11 threads: all 10 could have been created, while 5 is the first to run

• thread.h
• thread.c
• threadHello.c

• What is the difference between a lock and a condition variable?¹
• Why is it important that a thread release the held lock when it waits on a condition variable?²

Natural answer: the OS 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
• There is a thread name space
  • Thread ids (TIDs)
  • TIDs are integers (surprise!)
• Why "must" the kernel be responsible for creating/managing threads?
  • it's the scheduler

• OS now manages threads and processes / address spaces
  • all thread operations are implemented in the kernel
  • OS schedules all of the threads in a system
    • if one thread in a process blocks (e.g., on 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
      • that is, under programmer control
• Kernel threads are cheaper than processes
  • less state to allocate and initialize
• But, they're still pretty expensive for fine-grained use
  • orders of magnitude more expensive than a procedure call
  • thread operations are all system calls
    • context switch
    • argument checks

• There is an alternative to kernel threads
  • Note that thread management isn't doing anything that feels privileged
• 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)
    • each kernel thread is treated as a "virtual processor"
  • we call these user-level threads

• User-level threads are small and fast
  • managed entirely by user-level library
    • e.g., pthreads (libpthreads.a)
  • each thread is represented simply by a PC, registers, a stack, and a 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

• The OS schedules the kernel thread
• The kernel thread executes user code, including the thread support library and its associated thread scheduler
• The thread scheduler determines when a user-level 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