是libstdc ++线程中的ostream操作符<< hostile？

Question

ostream运营商<<采用num_put::put()了数字格式.我正在尝试遵循代码.我将链接到OSX文件,但类似的文件出现在我看到的其他一些系统上.在我看来,num_put::put()呼叫num_put::do_put(),呼叫
num_put::_M_insert_float(),其中calls __convert_from_v():

http://www.opensource.apple.com/source/libstdcxx/libstdcxx-60/include/c++/4.2.1/bits/c++locale.h
http://www.opensource.apple.com/source/libstdcxx/libstdcxx-60/include/c++/4.2.1/bits/locale_facets.tcc
http://www.opensource.apple.com/source/libstdcxx/libstdcxx-60/include/c++/4.2.1/bits/locale_facets.h

__convert_from_v()检查当前的全局语言环境,如果它与"C"不同,则调用setlocale()将全局语言环境设置为"C",然后用于vsnprintf()格式化数字,然后setlocale()再次调用以恢复为旧的语言环境.

由于setlocale()影响所有线程,因此在多线程应用程序中调用具有浮点数的ostream运算符似乎<<是不安全的,该应用程序将全局语言环境设置为"C"以外的其他位置.但那会很奇怪,所以我错过了什么？谢谢!

Answer 1

最新草案 (N3936) 特别对此提出警告：

\n\n

\xc2\xa7 18.10

\n\n

\n

6 对 setlocale 函数的调用可能会与对 setlocale 函数的其他调用或对受当前 C 语言环境影响的函数的调用引起数据争用。实现的行为应如同除 locale::global() 之外没有任何库函数调用 setlocale 函数一样。

\n

\n\n

较新版本的 GCC 限制调用LC_NUMERIC而不是LC_ALL，如果您使用 glibc > 2.2，则实现通过调用uselocale仅修改当前线程来完全避免问题（我猜在 OSX 上对您没有多大用处\xe2\x80\xa6） 。

\n\n

编辑：我更好地查看了来源

\n\n

尽管如果从另一个线程调用依赖于 C 语言环境的函数，而__convert_from_v另一个函数修改 C 语言环境，则通用语言环境模型可能会出现问题，但通用语言环境模型唯一支持的语言环境是"C"（这是在启动），因此这不是问题，除非将其他语言环境的支持添加到通用模型中。

\n\n

唯一可能出现问题的情况是 gcc 是使用 gnu 语言环境模型构建的，并且 glibc <= 2.2，这在 OSX 上不会发生。

\n