Index: doc/theses/colby_parsons_MMAth/text/channels.tex
===================================================================
--- doc/theses/colby_parsons_MMAth/text/channels.tex	(revision b51b2a66357efaa480b18720757dd93f78c38e23)
+++ doc/theses/colby_parsons_MMAth/text/channels.tex	(revision 8421d3fad6379460563c3a8922889a72c4d868fe)
@@ -300,9 +300,10 @@
 Implementing a barrier is interesting because threads are both producers and consumers on the barrier-internal channels, @entryWait@ and @barWait@.
 The outline for the barrier implementation starts by initially filling the @entryWait@ channel with $N$ tickets in the barrier constructor, allowing $N$ arriving threads to remove these values and enter the barrier.
-After @entryWait@ is empty, arriving threads block when removing from @entryWait@.
+After @entryWait@ is empty, arriving threads block when removing.
 However, the arriving threads that entered the barrier cannot leave the barrier until $N$ threads have arrived.
-Hence, the entering threads block on the @barWait@ channel until the $N$th arriving thread inserts $N-1$ elements into @barWait@ to unblock the $N-1$ threads calling @remove@ on the @barWait@ channel.
+Hence, the entering threads block on the empty @barWait@ channel until the $N$th arriving thread inserts $N-1$ elements into @barWait@ to unblock the $N-1$ threads calling @remove@.
 The race between these arriving threads blocking on @barWait@ and the $N$th thread inserting values into @barWait@ does not affect correctness;
 \ie an arriving thread may or may not block on channel @barWait@ to get its value.
+Finally, the last thread to remove from @barWait@ with ticket $N-2$, refills channel @entryWait@ with $N$ values to start the next group into the barrier.
 
 Now, the two channels makes termination synchronization between producers and consumers difficult.