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
About scheduler_lock #82
Comments
struct jump_context_data {
FiberEntity* self, *caller;
}; |
这儿不(只)在于FiberProc(fiber创建后第一次运行),在涉及到fiber::Mutex之类的场景,从pthread1加入wait-chain之后,可能立刻就会被pthread2从chain中弹出并准备执行,这时候需要某种同步机制达到「pthread2等待直到pthread1不再操作fiber_entity」,无论是spinlock,还是复用其他某个字段(比如fiber->state),最后对性能的影响应该都是类似的,相比之下spinlock更利于对整体代码的理解。 不过就性能而言,fiber调度的主要成本在于pthread2的唤醒,这儿多一个少一个atomic的操作应该实际上感知不到 |
不过现在这个写法,fiber的state就和schedulingGroup强绑定了,需要它才能去正确的得到fiber的state |
不排除我有什么地方记岔了,但是fiber的state应该只要能获取到scheduler_lock就可以访问,并不要求跟scheduling_group绑定 比如 |
噢好像,fiber单独拿出来使用也不能yield,要配合scheduling_group才能yield,也就不涉及waiting状态的改变。我的原意是指单独使用fiber的时候,去yield,fiber的状态没有变成waiting |
// |
https://github.com/Tencent/flare/blob/master/flare/fiber/alternatives.h#L35 这个,用来不依赖 |
thread id也有errno这个问题吗 |
flare/flare/fiber/this_fiber.h Line 48 in 37be012
flare/flare/fiber/detail/fiber_entity.h Line 88 in 37be012
|
有,其实用到thread-local storage都有可能有问题
这个id有需求可以返回,这个是fiber的id。但是async_test.cc那个测试里面测试的目的是「Dispatch方式运行的fiber会直接在caller的pthread里面运行」,所以比较的是threadid |
不是,这是另外一个话题了,我的意思是 flare/flare/fiber/this_fiber.h Line 48 in 37be012
我看这里只是打了个问号 |
flare/flare/fiber/detail/fiber_entity.h
Lines 90 to 106 in 37be012
flare/flare/fiber/detail/fiber_entity.h
Lines 354 to 356 in 37be012
或许可以利用一下这个Argument
context
,fiber
切换过去再将caller fiber
的State
改变,状态改变的时候就不需要这把锁了?The text was updated successfully, but these errors were encountered: