预计 boost::thread_specific_ptr<>::get() 的使用会很慢吗？有什么解决方法吗？
我目前正在使用 Valgrind 的“Callgrind”分析一个存在性能问题的应用程序。在查看分析数据时，似乎有 25% 的处理时间花费在主要用途为的应用程序的 boost::detail::get_tss_data 内部物理模拟和可视化。
get_tss_data 显然是由 thread_specic_ptr::get 调用的，
有人认为这是预期的吗？它通常暗示着其他具体的东西吗？
编辑：
我的平台是：Linux-2.6.32、x86、GCC 4.4.3、libc6-2.11.1/libpthread-2.11.1
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
thread_specific_ptr对 POSIX 系统使用pthread_setspecific/pthread_getspecific，这并不是最快的。如果您使用的是 POSIX 系统，则可以使用 __thread 存储说明符。但是，它只能与常量表达式的初始值设定项一起使用，例如 gcc 的 __thread
对于Windows，类似的说明符是
_declspec(thread)。thread_specific_ptrusespthread_setspecific/pthread_getspecificfor POSIX systems which is not the fastest possible.If you are on a POSIX system, you can use the
__threadstorage specifier. However, it can only be used with initializers that are constant expressions e.g gcc's __threadFor Windows, a similar specifier is
_declspec(thread).获取线程本地数据很可能涉及系统调用。系统调用跳转到中断向量，并且现在必须读取内核内存。所有这些都会杀死缓存。
因此，读取线程本地数据可能比读取普通变量要长得多。因此，将线程本地数据缓存到一些本地变量而不是频繁访问线程本地存储可能是一个好主意。
Obtaining thread local data will most probably involve a system call. System calls jump to an interrupt vector as well as now having to read kernel memory. All this kills the cache.
For this reason reading thread local data can much longer than a normal variable read. For this reason is may well be a good idea to cache thread local data some local variable an not make frequent accesses to thread local storage.