ZLMediaKit / ZLToolKit

一个基于C++11的轻量级网络框架,基于线程池技术可以实现大并发网络IO
MIT License
1.96k stars 583 forks source link

不会 notify_all() ? 什么 SB 实现。 #7

Closed lhmouse closed 6 years ago

lhmouse commented 6 years ago

https://github.com/xiongziliang/ZLToolKit/blob/7353a131b46ab6af46d9de23078076d1932f33fb/src/Thread/semaphore.h#L66

xia-chu commented 6 years ago

If there is a bug as you said

如果如你所说那真有bug了

TRANS_BY_GITHUB_AI_ASSISTANT

xia-chu commented 6 years ago

You're also a half-empty bucket.

看你也是半桶水

TRANS_BY_GITHUB_AI_ASSISTANT

lhmouse commented 6 years ago

I'm a half-baked programmer? Want some real stuff? You, a post(10), would need 10 times the syscall? zz no.

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

TRANS_BY_GITHUB_AI_ASSISTANT

xia-chu commented 6 years ago

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

lhmouse commented 6 years ago

Do you have an opinion when your count is greater than 1, you should notify_all()? By the way, since you rely on std::condition_variable, don't expect any efficiency.

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

TRANS_BY_GITHUB_AI_ASSISTANT

xia-chu commented 6 years ago

Incrementing the semaphore by n will wake up the waiting thread n times. If you change it like that, wouldn't it be messed up? What I want is to implement a semaphore for the fast platform, not a condition variable.

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

TRANS_BY_GITHUB_AI_ASSISTANT

lhmouse commented 6 years ago

It's like you don't have spurious wakeups unless you notify.

p.s. Is this level of skill being kind by saying someone is half-baked?

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

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

TRANS_BY_GITHUB_AI_ASSISTANT

lhmouse commented 6 years ago

How should I teach♂ you?

Your semaphore is still implemented based on mutex + condition variable, but condition variable is an unreliable protocol. According to the most common way of writing, the wait() operation of condition variable is written in a while loop. According to this way of writing, note that the P operation on the semaphore does not necessarily lead to the wait() of the condition variable, but the V operation on the semaphore (if the increment is not zero) will definitely lead to the signal() or broadcast() of the condition variable, so obviously the latter is more in need of optimization.

需要我怎么教♂育你呢?

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

TRANS_BY_GITHUB_AI_ASSISTANT

xia-chu commented 6 years ago

@lhmouse What I want is a semaphore. What the hell are you trying to achieve with notify_all? Is this issue title meant to discuss the problem? I'm limited in my abilities. I'm not building this library to make something super awesome, super high-end, or super complete. I'm just doing it for my other streaming media project. There are many open-source basic frameworks out there. Compared to them, this project is child's play.

In the semaphore + n operation, how do I know how many threads are waiting? Calling notify_one() n times is a more reliable approach, even though it involves n system calls. But first, we need to implement the functionality, then we can optimize performance. You can't even guarantee the functionality of notify_all(), so what's the point of talking about performance?

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

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

TRANS_BY_GITHUB_AI_ASSISTANT

xia-chu commented 6 years ago

@lhmouse If you have a better way to do it, please give me a revised code. I will be very grateful. Thank you

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

TRANS_BY_GITHUB_AI_ASSISTANT

lhmouse commented 6 years ago

How can it be "not guaranteed to work"? The reliability of the semaphore is guaranteed by the mutex, not the condition variable. Otherwise, what's the point of the while loop?

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

TRANS_BY_GITHUB_AI_ASSISTANT

xia-chu commented 6 years ago

Why don't you paste your modified code? I'll take a look and see if it works.

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

TRANS_BY_GITHUB_AI_ASSISTANT

lhmouse commented 6 years ago

Didn't I tell you how to fix it? Do I have to slap the patch in your face for you to understand?

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

Change it to

_condition.notify_all();

Will you die if you do?

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

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

改成

_condition.notify_all();

会死是不是?

TRANS_BY_GITHUB_AI_ASSISTANT