Changeset 5d81edb

Timestamp:

May 31, 2023, 8:45:46 AM (11 months ago)

Author:

Peter A. Buhr <pabuhr@…>

Branches:

ast-experimental, master

Children:

8421d3f

Parents:

d8d9c115

Message:

wording changes in channel chapter

File:

• doc/theses/colby_parsons_MMAth/text/channels.tex (modified) (1 diff)

doc/theses/colby_parsons_MMAth/text/channels.tex

@@ -300 +300 @@
 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.