Added Wait Group section.
diff --git a/MutexOrChannel.md b/MutexOrChannel.md
index 1b4e7d8..0f41fd2 100644
--- a/MutexOrChannel.md
+++ b/MutexOrChannel.md
@@ -12,13 +12,19 @@
As a general guide, though:
-| **Channel** | **Mutex**|
-|:------------|:---------|
+| **Channel** | **Mutex** |
+|:------------|:----------|
| passing ownership of data,<br />distributing units of work,<br /> communicating async results | caches,<br />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
