线程本地存储在哪些平台上有限,有多少可用?

Jos*_*vin 15 c++ multithreading cross-platform boost-thread thread-local

我最近意识到线程本地存储在某些平台上是有限的.例如,C++库boost :: thread read的文档:

"注意:可以创建的特定于线程的存储对象的数量存在特定于实现的限制,并且此限制可能很小."

我一直在寻找尝试找出不同平台的限制,但我找不到权威表.如果您正在编写使用TLS的跨平台应用程序,这是一个重要问题.Linux是我找到信息的唯一平台,以Ingo Monar补丁的形式在2002年发送到内核列表添加TLS支持,他提到"TLS区域的数量是无限的,并且没有相关的额外分配开销支持TLS." 如果在2009年仍然如此(是吗?)非常漂亮.

但是今天Linux怎么样?OS X?视窗?的Solaris?嵌入式操作系统?对于在多种体系结构上运行的操作系统,它是否因架构而异?

编辑:如果您对可能存在限制的原因感到好奇,请考虑预先分配线程本地存储的空间,因此您将在每个线程上支付费用.面对很多线程,即使是少量也是一个问题.

bdo*_*lan 11

在Linux上,如果使用__threadTLS数据,唯一的限制是由可用的地址空间设置的,因为这些数据只是被分配为gs(在x86上)或fs(在x86-64上)段描述符引用的常规RAM .请注意,在某些情况下,动态加载库使用的TLS数据的分配可以在不使用该TLS数据的线程中省略.

pthread_key_create然而,由朋友和朋友分配的TLS 仅限于PTHREAD_KEYS_MAX插槽(这适用于所有符合标准的pthreads实现).

有关Linux上TLS实现的更多信息,请参阅针对线程局部存储的ELF处理适用于Linux的本机POSIX线程库.

也就是说,如果您需要可移植性,最好的办法是尽量减少TLS的使用 - 在TLS中放置一个指针,并将您需要的所有内容都挂在指针上.


rme*_*dor 0

Boost 文档可能只是简单地谈论一般的可配置限制,而不一定是平台的某些硬限制。在 Linux 上,ulimit命令限制进程可以拥有的资源(线程数、堆栈大小、内存和一堆其他内容)。这将间接影响您的线程本地存储。在我的系统上,ulimit 中似乎没有特定于线程本地存储的条目。其他平台可能有办法自行指定。另外,我认为在许多多处理器系统中,线程本地存储将位于专用于该 CPU 的内存中,因此在系统整体内存耗尽之前,您可能会遇到物理内存的限制。我假设在这种情况下存在某种后备行为来定位主内存中的数据,但我不知道。正如你所知,我猜测了很多。希望它仍然引导您走向正确的方向......