我正在实现一个非常轻量的pthread替换库.为什么要完全禁用__thread有几个原因.
>这是浪费内存.如果我要创建一千个与使用__thread声明变量的上下文无关的线程,它们仍将分配程序,但仍将分配该数据字节大小的1000 *,并且从不使用它.它根本不是与大容量并发模型兼容的内存.如果我们需要只有8K堆栈的极轻量级的光纤,那么只有4K的TLS块将占用每个线程所用内存的50％.在某些情况下,TLS开销会很大.
> TLS是一个复杂的标准,我根本没有时间/资源来支持它.太贵了.我个人认为该标准设计不当.它应该定义了链接程序必须提供的标准功能,以便线程库可以控制TLS分配的位置,并插入相关的偏移量和所需的地址.同样,标准ELF实现也感染了pthread,希望pthread大小的结构能够计算偏移量,从而使其很难适应其他东西.
>这只是一个糟糕的模式.它鼓励使用全局变量并创建具有静态函数/副作用的函数.如果我们正在创建易于分析的正确程序,那么这不是我们想要的领域.
>如果我们真的需要用于跟踪幕后线程状态的魔术的“线程上下文”(例如分配或取消跟踪),为什么不仅仅公开TLS用于首先了解该上下文的魔术呢？我个人将直接使用％fs注册.由于明显的原因,这在库中是不可能的,但是为什么它们从一开始就应该具有线程意识？为什么不正确地设计它们,以便它们在参数列表中首先获得所需的上下文相关数据？
我的问题很简单：如果您不小心使用__thread支持并让clang发出错误,最简单的方法是什么？如果加载刚需要TLS的动态库,如何得到错误？
解决方法:
我相信最简单的方法是无条件地向CFLAGS中添加这样的内容(如果您希望它是系统全局的,则可能来自clang的gcc specfile等效文件)：
-D__thread='^-^'
在C程序的任何位置,右侧可以是语法上无效的任何东西(违反约束).
为了防止使用TLS加载库,您必须修补链接程序和/或动态链接程序以拒绝它们.如果您只是在谈论dlopen,则程序可以首先读取文件并解析TLS重定位的ELF标头,然后拒绝该库(不将其传递给dlopen)(如果有).甚至可以使用LD_PRELOAD包装器来实现.
我同意您的看法,特别是在当前实施中,TLS是应该避免使用的一种方法,但是请问您是否已衡量成本？我认为,在旨在使用它的系统上将其完全淘汰非常困难,而且还有很多悬而未决的东西可以减少膨胀.您正在使用哪个libc？如果是glibc,我可以肯定的是,这些天glibc本身在内部使用了很多TLS …当然,如果您正在编写自己的线程实现,则将需要与标准库的其余部分进行大量交互,所以也许您已经在修补它…？
顺便说一下(后面是无耻的插件),我们在musl libc中有an extremely light-weight threads implementation,目前没有TLS.我认为与另一个libc集成并不容易(而且我敢肯定,如果您正在编写自己的libc,您将发现与glibc集成非常困难,尤其是glibc的动态链接器,它希望支持TLS),但是如果您可以按原样使用整个库,则它可能满足您对特定项目的需求,或者可以借用有用的代码(许可证为MIT).
标签：pthreads,c-3,linux 来源： https://codeday.me/bug/20191127/2075497.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。