-
Notifications
You must be signed in to change notification settings - Fork 166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
queue: 基于semaphore的并发阻塞队列实现 #129
Conversation
-主要改造了concurrent_array_blocking_queue的实现,将原来基于cond的实现改造成基于semaphore的实现
-补充出队入队超时时,当前goroutine主动归还信号的逻辑,防止信号泄露 -修改出队入队sema变量命名,使变量含义更直观
-在注释//和注释文本之间加上空格
从逻辑上来看并不会引起什么问题,之前我还担心引发死锁的问题,目前来看也不会。
前者是一个 CPU 的问题,也就是 goroutine 被唤醒然后又沉睡;后者更加像是一个内存分配的问题,因为 semaphore 一次只会唤醒一个。 你们总体上倾向于哪种? |
要是问题你解决了就记得点一下 resolve |
-在本地执行make check -提交go.sum文件 -在changelog文件中提交合并请求内容
Codecov Report
@@ Coverage Diff @@
## dev #129 +/- ##
==========================================
+ Coverage 95.17% 95.24% +0.06%
==========================================
Files 34 34
Lines 1699 1723 +24
==========================================
+ Hits 1617 1641 +24
Misses 64 64
Partials 18 18
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
-在本地执行make check
我还是把这个合并进去了。核心就是:
|
@flycash 广播的实现,channel与监听的协程比是1:N,semaphore的实现是1:1. 我好奇我们所担心的channel开销多低有多大. 所以我修改了一下semaphore包内semaphore_bench_test.go的BenchmarkAcquireSeq基准测试 发现一个不太符合我们直觉的现象——开销为0, 我们担心的channel创建开销并不存在, 不知道是我Go版本的问题?(我用的是1.19)还是我测的不对?或者真的就是没有这个开销. 我记得在课程也出现过这个现象,——开销就是为0
|
-主要改造了concurrent_array_blocking_queue的实现,将原来基于cond的实现改造成基于semaphore的实现