diff --git a/MutexOrChannel.md b/MutexOrChannel.md index 0f41fd27..b1826d04 100644 --- a/MutexOrChannel.md +++ b/MutexOrChannel.md @@ -20,9 +20,11 @@ If you ever find your sync.Mutex locking rules are getting too complex, ask your ## Wait Group -Another important category is sync.WaitGroup. These allow co-operating goroutines to collectively wait for a threshold event before proceeding independently again. This is useful typically in two cases. Firstly, when 'cleaning up', a sync.WaitGroup can be used to ensure that all goroutines - including the main one - wait before all terminating at once. +Another important category is sync.WaitGroup. These allow co-operating goroutines to collectively wait for a threshold event before proceeding independently again. This is useful typically in two cases. -The second more general case is of a cyclic algorithm that involves independent work by the goroutines, then waiting on a barrier before proceeding independently. Data might be exchanged at the barrier event. This strategy is the basis of [Bulk Synchronous Parallelism](https://en.wikipedia.org/wiki/Bulk_synchronous_parallel) (BSP). +Firstly, when 'cleaning up', a sync.WaitGroup can be used to ensure that all goroutines - including the main one - wait before all terminating cleanly. + +The second more general case is of a cyclic algorithm that involves a set of goroutines that all work independently for a while, then all wait on a barrier, before proceeding independently again. This pattern might be repeated many times. Data might be exchanged at the barrier event. This strategy is the basis of [Bulk Synchronous Parallelism](https://en.wikipedia.org/wiki/Bulk_synchronous_parallel) (BSP). ## More Info