POSIX Threads

01 Lab overview

This lab contributes to U4.1 through U4.4, and to course learning outcomes CLO2, CLO6, and CLO8.

02 Learning objectives

03 Background

3.1 Threads and processes

A thread is the smallest unit of execution the operating system can schedule. A process contains one or more threads; all threads in a process share the process's address space, open file descriptors, signal handlers, and other resources. Each thread has its own stack, registers, and thread-local storage. On Linux, threads are created with the clone system call and are visible in /proc/<pid>/task/.

3.2 The pthreads API

POSIX Threads (pthreads) is the standard thread API defined by IEEE 1003.1c. The principal calls are:

pthread_create(pthread_t *tid, const pthread_attr_t *attr, void *(*start)(void *), void *arg)

Creates a new thread that begins execution at start(arg). The thread's identifier is written to *tid. Returns 0 on success, an error number otherwise.

pthread_join(pthread_t tid, void **retval)

Blocks the calling thread until the thread tid terminates. If retval is non-NULL, the thread's return value is stored there.

pthread_exit(void *retval)

Terminates the calling thread and makes retval available to a joiner.

pthread_self(void)

Returns the calling thread's identifier.

pthread_detach(pthread_t tid)

Marks the thread as detached so its resources are reclaimed automatically upon termination.

3.3 Compilation

Multithreaded programs must be linked against the pthreads library. With gcc, pass -pthread:

gcc -Wall -Wextra -O2 -pthread -o hello hello.c

On modern glibc, -pthread is sufficient; on older systems you may also need -lpthread. Omitting the flag produces undefined behaviour (often a link-time error or a run-time failure in pthread_create).

3.4 The anatomy of a multithreaded program

A minimal pthreads program has four parts: the thread function, the thread identifiers, the creation loop, and the join loop. The program below creates 4 worker threads and waits for them.

#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>

#define N 4

static void *worker(void *arg) {
    long id = (long)arg;
    printf("worker %ld: hello from thread %lu\n",
           id, (unsigned long)pthread_self());
    return (void *)(id * 10);
}

int main(void) {
    pthread_t tid[N];
    for (long i = 0; i < N; i++) {
        if (pthread_create(&tid[i], NULL, worker, (void *)i) != 0) {
            perror("pthread_create");
            exit(EXIT_FAILURE);
        }
    }
    for (int i = 0; i < N; i++) {
        void *ret;
        if (pthread_join(tid[i], &ret) != 0) {
            perror("pthread_join");
            exit(EXIT_FAILURE);
        }
        printf("joined thread %d, returned %ld\n", i, (long)ret);
    }
    return 0;
}
          

04 Guided activities

Activity 4.1 — Build and run the canonical pthreads program

1. Create the lab directory:

   mkdir -p ~/comp3150/lab3 && cd ~/comp3150/lab3

2. Copy the program in § 3.4 into hello_threads.c.
3. Compile and run it:

   gcc -Wall -Wextra -O2 -pthread -o hello_threads hello_threads.c
   ./hello_threads

4. Observe the output. In what order do the worker threads print? Is the order stable across runs? Why or why not?
5. Compile the same program without -pthread and record what happens. Restore the correct compilation.

Activity 4.2 — Passing and returning values

1. Extend the program so each worker receives a heap-allocated struct containing an id and a delay_ms field.
2. Have each worker usleep(delay_ms * 1000), then return a heap-allocated result that the main thread frees after pthread_join.
3. Run the program with delays that differ by a factor of 10 and observe the completion order with time ./hello_threads.
4. Modify one worker to pass the address of a stack variable of the loop instead of a heap copy, and observe the result. Explain why this is incorrect.

Activity 4.3 — Threads are visible in the kernel

1. Run the program with a long sleep in the main thread after creating the workers, and identify the process's PID.
2. In a second terminal, run:

   ls /proc/<pid>/task/
   cat /proc/<pid>/status | grep Threads

3. Compare the thread IDs in /proc/<pid>/task/ with the pthreads identifiers printed by the program. Are they the same?
4. Run ps -L -o pid,tid,comm -p <pid> and record the output.

Activity 4.4 — Scheduling and concurrency

1. Write a program that creates n threads, each performing a CPU-bound loop that increments a counter until a shared deadline.
2. Run the program with n = 1, 2, 4, 8, 16 and record the total wall-clock time for each configuration. Use taskset -c 0 ./program to pin the process to a single core, and repeat without pinning.
3. Plot the times. What is the speedup? At what value of n does it saturate?
4. Explain the difference between the pinned and the unpinned runs in terms of the kernel's thread scheduling.

Activity 4.5 — The first race condition

1. Write a program that creates n threads, each incrementing a shared global counter 1,000,000 times:

   volatile long counter = 0;
   void *worker(void *arg) {
       for (long i = 0; i < 1000000; i++) counter++;
       return NULL;
   }

2. Run the program with n = 1, n = 2, and n = 4. Record the final value of counter each time.
3. Repeat the experiment ten times for each n. Is the final value always the expected n × 1,000,000?
4. Using objdump -d, inspect the assembly for counter++. Identify the three instructions (load, increment, store) and explain how the interleaving of two threads produces a lost update.
5. Do not fix the race in this lab; you will fix it in Lab 5.

05 Exercises

06 Deliverables

Submit a single archive (tar.gz or zip) named lab3-<lastname>-<studentnumber>.tar.gz containing:

• hello_threads.c (or the final version after all activities) with your name and student number at the top.
• race.c — the program from Activity 4.5, with the objdump output's relevant fragment in a comment.
• Makefile with a default target building all programs, a clean target, and the correct -pthread flags.
• results.txt — the output of all runs (Activities 4.1–4.5 and Exercises 1–5), with the commands that produced them.
• report.md (or report.pdf) — the lab report described below.

Lab report

The report should be 3–4 pages (excluding code) and contain:

1. Environment. The output of uname -a, gcc --version, nproc, and lscpu's relevant lines.
2. Activity results. For each activity, the command used, the observed output, and a one-paragraph interpretation.
3. Exercise results. For each exercise, a short answer supported by the relevant output or code fragment.
4. Race condition analysis. The objdump fragment, a step-by-step trace of two interleaved threads that produce a lost update, and a statement of the correct final value that is not observed.
5. Reflection. Two or three paragraphs on the difference between concurrency (the composition of independent activities) and parallelism (the simultaneous execution on several cores), as observed in Activity 4.4.

07 Grading rubric

Late submission penalty: 10% per day, up to a maximum of three days, after which the lab is accepted only with documented extenuating circumstances.

08 Knowledge check

09 References

• IEEE Std 1003.1c — POSIX Threads. The standard's definition of the pthreads API.
• Linux man-pages: man 7 pthreads, man 3 pthread_create, man 3 pthread_join, man 3 pthread_exit, man 3 pthread_self, man 3 pthread_detach.
• Kerrisk, M. The Linux Programming Interface. No Starch Press, 2010. Chapters 29–33.
• Butenhof, D. R. Programming with POSIX Threads. Addison-Wesley, 1997.
• Arpaci-Dusseau, R. H., & Arpaci-Dusseau, A. C. Operating Systems: Three Easy Pieces. Chapters 26 and 27.