From 901b5a65e540676503565480c775d68beb68746a Mon Sep 17 00:00:00 2001 From: Rick Beton Date: Thu, 19 Mar 2015 14:52:22 +0000 Subject: [PATCH] Added Wait Group section. --- MutexOrChannel.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/MutexOrChannel.md b/MutexOrChannel.md index 1b4e7d8e..0f41fd27 100644 --- a/MutexOrChannel.md +++ b/MutexOrChannel.md @@ -12,13 +12,19 @@ A common Go newbie mistake is to over-use channels and goroutines just because i As a general guide, though: -| **Channel** | **Mutex**| -|:------------|:---------| +| **Channel** | **Mutex** | +|:------------|:----------| | passing ownership of data,
distributing units of work,
communicating async results | caches,
state | If you ever find your sync.Mutex locking rules are getting too complex, ask yourself whether using channel(s) might be simpler. +## 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. + +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). + ## More Info * Channels in Effective Go: http://golang.org/doc/effective_go.html#channels - * The sync package: http://golang.org/pkg/sync/ + * The sync package: http://golang.org/pkg/sync/ \ No newline at end of file