NPTL:什么是 MULTIPLE_THREADS_OFFSET 以及如何设置
nptl/glibc 中有相当大的 commit-git:
http://sourceware.org/git/?p=glibc.git;a=commit;h=e51deae7f6ba2e490d5faeb8fbf4eeb32ae8f1ee
作者:Ulrich Drepper 和 Jakub Jelinek @ 2007
在 SMP 代码中,lll_unlock 被修改为
+# define __lll_unlock_asm "cmpl $0, %%gs:%P3\n\t" \
+ "je 0f\n\t" \
+ "lock\n" \
+ "0:\tsubl $1,%0\n\t"
其中 $0
是 futex 地址 零和 % P3 是 MULTIPLE_THREADS_OFFSET 常量。
那么,$gs:MULTIPLE_THREADS_OFFSET
(又名 $gs:(offsetof (tcbhead_t, multiple_threads))
中存储了什么?这个值在程序的生命周期中如何更改?
There was rather huge commit-git into nptl/glibc:
http://sourceware.org/git/?p=glibc.git;a=commit;h=e51deae7f6ba2e490d5faeb8fbf4eeb32ae8f1ee
by Ulrich Drepper and Jakub Jelinek @ 2007
I interested in the change to lll_lock/lll_unlock
In SMP code, lll_unlock was modified to
+# define __lll_unlock_asm "cmpl $0, %%gs:%P3\n\t" \
+ "je 0f\n\t" \
+ "lock\n" \
+ "0:\tsubl $1,%0\n\t"
where $0
is the futex address Zero and %P3
is MULTIPLE_THREADS_OFFSET constant.
So, What is stored at $gs:MULTIPLE_THREADS_OFFSET
(aka $gs:(offsetof (tcbhead_t, multiple_threads))
? How this value is changed in the lifetime of program?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
这种跳转是针对单线程进程中使用多线程代码的情况进行的优化。如果您在单线程进程中使用此代码,则不需要 subl 指令的“lock”前缀,因为不需要原子性,因此可以在运行时消除。指令会自动产生 CPU 级别的运行时开销。
因此,简短的答案是,multiple_threads 字段是一个布尔值,它告诉我们是否实际上处于多线程运行时环境中。
This jump is an optimization for the case where multi-threaded code is used in a single-threaded process. If you are using this code in a single-threaded process, then the 'lock' prefix to the subl instruction is not needed because atomically is not needed, and therefore can be eliminated in run-time. Instruction atomically incurs a run-time overhead at the CPU level.
So, the short answer is that
multiple_threads
field is a boolean that tells whether we are actually in a multi-threaded run-time environment.