This (lengthy) exercise asks you to compare process-based and thread-based designs on two axes:

  • Design: when would you choose one over the other, and why?
  • Cost: what do you pay for each, both in speedup and in switch overhead?

The goal is to connect the OS mechanisms in the lecture to concrete design choices you can justify with measurements.

Experiment with the following programs:

Part 1: Design — When and Why

Answer.

  1. Responsiveness. What design choice can make a GUI application non-responsive and under what condition, and what design choice can fix it? Use the Java π estimator to illustrate.
  2. Design trade-off. Is there a benefit you can get from multi-process design but not from multi-threaded design, or vice versa? Give a concrete example from the programs you studied.

Part 2: Protection vs. Cost — The Echo Server

The Echo server demonstrates both a benefit and a cost of the process-per-request design.

A. Protection

Hypothesis. If the server uses a process per client, then a crash in one client’s handler does not affect other clients.

Experiment. Run the server. Connect two clients. Identify the child process handling one client (ps axjf) and kill it (kill -9 <pid>). Then:

  1. Show that the other client’s connection is still alive.
  2. Show that a new client can still connect.

Evidence to include. The ps output showing the server’s child processes before and after the kill, the PID you killed, and a transcript of the surviving client.

Also answer. What would happen in a thread-per-client server if one handler dereferenced a null pointer and crashed? Why?

B. Cost: Two Questions

Question 1 (capacity). Can a thread-per-client design host more concurrent clients than a process-per-client design, for the same memory footprint?

Question 2 (throughput). Can a thread-per-client design accept more clients per second than a process-per-client design?

These are different questions. A design can win on one and lose on the other. Your job is to measure both and explain what you observe.

Experiment (capacity). For each server design:

  1. With no clients connected, record the server’s RSS.
  2. Open N clients (N = 1, 10, 50) and keep them connected.
  3. Record RSS and process/thread count as N grows.
  4. Plot footprint versus N.

Experiment (throughput). For each server design:

  1. Write a client that connects, sends a short message, receives the echo, and disconnects.
  2. Run K such clients in parallel and measure how long until all K complete.
  3. Compute clients accepted per second for K = 100, 1000.

Evidence to include. A table of design, N (or K), process count, thread count, and total RSS or elapsed time. The ps command you used.

Questions to answer.

  1. Which design hosts more clients per MB of memory? By how much?
  2. Which design accepts more clients per second? By how much?
  3. Do the two questions have the same answer? If not, why not?
  4. What does the process-per-client design buy you in exchange for the extra memory? Connect this to Part A.

Part 3: Speedup — Parallelism and Amdahl’s Law

Compare the single-process, multi-process, and multi-thread π estimators.

  1. Run each with N = 1, 2, 4, 8 workers. Record wall-clock time and speedup relative to N = 1.
  2. Determine the number of logical CPUs M on your machine. Plot speedup versus N for each program.
  3. Where does the speedup flatten, and how does that relate to M?
  4. Relate your results to Amdahl’s law: estimate the serial portion S from your data.
  5. Is there an observable difference between the multi-process and multi-thread estimators at N = M? Predict first, then measure and explain.

Part 4: Switch Cost — What You Pay Per Switch

Watch:

Run umcontext and umthread. Using the results, explain and contrast:

  • What state is saved and restored in a kernel thread context versus a user-level thread context?
  • What does the kernel see in each case?
  • Why is the user-level switch cheaper?
  • How does this connect to the “Why a Thread Switch Is Cheaper” slide from the deck?

Deliverable

A 10-minute presentation (7 minutes presentation, 3 minutes Q&A) covering Parts 1–4. Where a question asks for a measurement, include the command and the number.

Further Reading