添加 CountDownLatch

[zhcpku]

添加了 CountDownLatch，一个类似 golang 中 sync.WaitGroup 的工具类

[dearbird]

1. 为啥没有 WaitGroup的 add 接口，干脆类名就叫WaitGroup就好了。
2. --mFlyingCount 操作不是原子的，多线程会有风险。是不是换成 atomic
3. 直接yield，如果是任务比较少的情况下，cpu会占满吧？

[zhcpku]

1. 为啥没有 WaitGroup的 add 接口，干脆类名就叫WaitGroup就好了。
   Add 必要性不是很大，只要初始化的时候制定要等待的coroutine就够用了
2. --mFlyingCount 操作不是原子的，多线程会有风险。是不是换成 atomic
   Done
3. 直接yield，如果是任务比较少的情况下，cpu会占满吧？
   task比线程数少的时候，增加睡眠等待

[dearbird]

1. 动态创建携程的时候很有用，比如http 服务器， 可以等待所有请求都结束后再关闭服务。
3. 这个实现感觉还是比较奇怪，为啥不采用信号的方式？比如wait 在channel 上， done 的时候写chan， wait 唤醒后检查下计数。

[zhcpku]

1. 动态创建携程的时候很有用，比如http 服务器， 可以等待所有请求都结束后再关闭服务。
   原来是这种场景，可以的。
2. 这个实现感觉还是比较奇怪，为啥不采用信号的方式？比如wait 在channel 上， done 的时候写chan， wait 唤醒后检查下计数。
   考虑过用n个不带缓冲的channel来实现，done的时候写，wait'里阻塞读，非常简单，但是开销比较大；用带缓冲的channel，检查size的话，还是要手动yield/sleep，就没有区别了啊

[dearbird]

换成在done 的时候判断计数为0再close chan， wait 直接block 在read chan 上？

[zhcpku]

换成在done 的时候判断计数为0再close chan， wait 直接block 在read chan 上？
这个好，一个计数器+一个chan就够了！

[zhcpku]

刚才还想到一种方式是，可以用一个不带缓冲的channel，由wait来写n次，done的时候读出来，不过这种会导致切换次数增加，不如上面的好

[zhcpku]

直接使用mutex+condition_variable的方案实现CountDownLatch