cap 和 running 比较的问题 about ants

[naiba]

加锁后资源消耗会增加，性能会下降很多，所以是加锁确保池数量还是不加锁保证性能呢？

[panjf2000]

并发量不大的情况下还是建议直接用goroutine，不然池化未必比裸用goroutine性能好，甚至会下降。

[naiba]

上面关于比较池容量跟运行中worker数量的问题怎么看 @panjf20002019年3月12日 19:37，Andy Pan <[email protected]>写道：并发量不大的情况下还是建议直接用goroutine，不然池化未必比裸用goroutine性能好，甚至会下降。 —You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or mute the thread.

[panjf2000]

那个compare操作的确不是原子操作，一种潜在的可能是：在比较过程中，某个worker结束任务了，把running数减一了，这可能导致pool有轻微的goroutine数量溢出。但是，

第一，发生的概率很小而且也只会是轻微溢出，我觉得在容忍限度以内；

第二， 如果要完全保证数据强正确的话，得再加锁，但这样不仅会让代码更加复杂，而且性能也会有比较大的下降，我觉得有点舍本逐末了。

目前我没想到既能保证性能又能保证数值绝对正确的实现方法，这个我后续有空再思考下，要是你有好的方法的话也欢迎提个PR我们一起讨论下😀，我先把issue设置成enhancement，以后慢慢优化。

[naiba]

@panjf2000  我也没想到，哈哈，我试过了，加了锁内存跟时间都快赶上直接用原生了。我感觉这个也是可以接受的，发出来看你做的时候怎么想的2019年3月12日 20:01，Andy Pan <[email protected]>写道：那个compare操作的确不是原子操作，一种潜在的可能是：在比较过程中，某个worker结束任务了，把running数减一了，这可能导致pool有轻微的goroutine数量溢出。但是，第一，发生的可能性比较小而且也只会是轻微溢出，我觉得在容忍限度以内；第二， 如果要精确保证数据正确的话，得再加锁，这样不仅会让代码更加复杂，而且性能也会有比较大的下降，我觉得有点舍本逐末了。 目前我没想到既能保证性能又能保证数值绝对正确的实现方法，这个我后续有空再思考下，要是你有好的方法的话也欢迎提个PR我们一起讨论下😀，我先把issue设置成enhancement，以后慢慢优化。 —You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or mute the thread.