Skip to content
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

为什么brpc框架内部大部分计时都没有使用 MONOTONIC,是有性能或其他方面的考虑吗? #2763

Open
synckey opened this issue Sep 12, 2024 · 6 comments
Labels
enhancement improvements on existing features

Comments

@synckey
Copy link

synckey commented Sep 12, 2024

Is your feature request related to a problem? (你需要的功能是否与某个问题有关?)

brpc 中的很多超时和唤醒逻辑都使用了墙上时钟,在系统时钟跳变时会产生很多问题。

比如以下代码:

请求超时时间:https://github.com/apache/brpc/blob/master/src/brpc/channel.cpp#L552

条件变量等待时间:https://github.com/apache/brpc/blob/master/src/bthread/condition_variable.h#L75

sleep时间:https://github.com/apache/brpc/blob/master/src/bthread/task_group.cpp#L775

Describe the solution you'd like (描述你期望的解决方法)

切换成 monotonic clock ?

Describe alternatives you've considered (描述你想到的折衷方案)
No

@wanghenshui
Copy link

你说的是对的,提一个PR更好

@chenBright
Copy link
Contributor

chenBright commented Sep 26, 2024

是的,我们这边遇到过这类问题——NTP误差或人为操作等原因导致的时钟跳变会导致触发时机提前或者延后。

对于进程内的计时,用单调时钟更合理,避免时钟跳变的影响。

之前尝试改了一下定时器的实现,运行是没有问题的。目前考虑:框架内部计时统一使用单调时钟。对于已经对外的墙上时钟接口,内部转成单调时钟。另外提供对应的单调时钟接口。但是pthread锁相关接口用的是墙上时间。

@wwbmmm 有什么建议吗?

@wwbmmm
Copy link
Contributor

wwbmmm commented Sep 26, 2024

是的,我们这边遇到过这类问题——NTP误差或人为操作等原因导致的时钟跳变会导致触发时机提前或者延后。

对于进程内的计时,用单调时钟更合理,避免时钟跳变的影响。

之前尝试改了一下定时器的实现,运行是没有问题的。目前考虑:框架内部计时统一使用单调时钟。对于已经对外的墙上时钟接口,内部转成单调时钟。另外提供对应的单调时钟接口。但是pthread锁相关接口用的是墙上时间。

@wwbmmm 有什么建议吗?

我看pthread提供了pthread_condattr_setclock来设置时钟类型,我们是否也可以提供相应的选项?

@chenBright
Copy link
Contributor

支持设置时钟类型,这样更灵活,但是TimerThread得同时支持两种时钟模式,复杂度可能会变大。

@wwbmmm
Copy link
Contributor

wwbmmm commented Sep 26, 2024

支持设置时钟类型,这样更灵活,但是TimerThread得同时支持两种时钟模式,复杂度可能会变大。

太复杂就没必要了,看实际需求吧,RPC的需求是不是用单调时钟都可以满足?

@chenBright
Copy link
Contributor

是的,RPC用单调时钟就可以满足超时的需求了。

@chenBright chenBright added the enhancement improvements on existing features label Oct 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement improvements on existing features
Projects
None yet
Development

No branches or pull requests

4 participants