Ch34 Discussion
Discussion Guide
Warm-up (think–pair–share, 5 min). "In OpenMP, two threads could both write the same cell and race. In MPI, can two processes race on the temperature field? Why or why not — and if not, what new worry replaces it?" Surfaces the private-memory model and reframes the hazard as communication correctness (spaced-review Q4).
Main discussion (15–20 min).
1. Read the deadlock. Put the two-send-first exchange on the board. Ask: "Trace what every process is doing
at the same instant. Who is receiving?" Lead them to "nobody — all sending." Then: "So why did it pass the
test?" Introduce eager vs rendezvous. This is the chapter's most important 8 minutes; the pattern recurs in
every real MPI code they will write.
2. reduce vs allreduce, as a correctness question. Give them the convergence loop from Case Study 2 and ask:
"If we used mpi_reduce (root-only) instead of mpi_allreduce for the stopping test, what happens?" Lead
to: non-root ranks never see the exit, loop on, and hang at the next collective. Cements that the choice
is about correctness, not convenience.
3. Why is the kernel unchanged across three parallel models? Show the coarray (Ch. 32), OpenMP (Ch. 33), and
MPI update side by side (same five-point stencil). Ask what design decision made that possible (Ch. 24's
read-old/write-new two-array update → data-parallel interior). Connects the whole part.
Group activity (12 min). In pairs, students take the broken exchange_halos from Case Study 1 and (a)
identify the deadlock, (b) rewrite it with mpi_sendrecv and MPI_PROC_NULL, and (c) state the verification
they would run to prove it correct (the -np 1 vs -np 2 identical-field check). Collect two or three and
critique against §34.4. Strong pairs can also spot the exchange-after-update ordering bug.
Exit ticket. "(a) Write the seven arguments of mpi_send in order. (b) Two ranks each mpi_send to the
other first — what happens, and what one call fixes it? (c) You need every rank to know the global maximum
change to decide whether to stop — which collective, and why not the other reduce?" (Answers: (a) buf, count,
datatype, dest, tag, comm, ierr; (b) deadlock risk — works small, hangs large; mpi_sendrecv; (c)
mpi_allreduce, because every rank must see the result to exit together — mpi_reduce would strand the
non-root ranks.)