不会 notify_all() ？ 什么 SB 实现。 about zltoolkit

[xia-chu]

如果如你所说那真有bug了

[xia-chu]

看你也是半桶水

[lhmouse]

我半桶水？要干货不？你一个 post(10) 难道 10 次 syscall ？zz 不。

[xia-chu]

@lhmouse 你看清楚在骂人zz好吗？这个是信号量实现，难道信号量+1要唤醒所有的线程吗？到底谁是智障？

[lhmouse]

你那个 count 大于 1 的时候就应该 notify_all() 有意见？
顺便，你既然依赖 std::condition_variable 就别指望什么效率了。

[xia-chu]

信号量加n次就唤醒等待的线程n次 按你那样改 那岂不是乱套了? 我要的是实现快平台的信号量 不是条件变量

[lhmouse]

好像你不 notify 就没有 spurious wakeup 似的。

p.s. 这水平好意说人家半桶水？

[lhmouse]

需要我怎么教♂育你呢？

你的 semaphore 依然是基于 mutex + condition variable 实现的，然而 condition variable 是一个 不可靠的 protocol 。按照最通常的写法， condition variable 的 wait() 操作是写在一个 while 循环里的。按照这种写法 ，注意，对 semaphore 的 P 操作并不一定会导致对其中的 condition variable 的 wait()， 但是对 semaphore 的 V 操作（如果增量不是零）一定会导致对 condition variable 的 signal() 或 broadcast()，所以显然 后者才是更需要优化的。

[xia-chu]

@lhmouse 我要的是信号量 你要notify_all到底要实现什么鬼？你这issue标题是要探讨问题？我是水平有限 ，我做这个库不是要搞个多么牛逼多么高大上多么健全的玩意，我只是为了我另外一个流媒体项目服务，开源的基础框架很多，相比而言，这个项目简直是小儿科。

在对信号量+n操作中，我咋知道有多少条线程在等待？notify_one() n次是比较靠谱的做法，虽然有n次系统调用，但是先实现功能然后才有性能优化，你直接来个notify_all()功能都不能保证，谈性能有什么意义？

[xia-chu]

@lhmouse 如果你有更高明的做法，请给我一份修改后的代码 我将感激不尽 谢谢

[lhmouse]

怎么就“不保证功能”了？ semaphore 的可靠性是 mutex 保证的又不是 condition variable 保证的，否则还要 while 干啥。

[xia-chu]

要不你把你修改后的代码贴出来？我看看行不行

[lhmouse]

我没告诉你怎么改吗？是不是把 patch 糊你脸上才算告诉你？

while (n--) {
	_condition.notify_one();
}

改成

_condition.notify_all();

会死是不是？