wwbmmm commented on issue #1693: URL: https://github.com/apache/incubator-brpc/issues/1693#issuecomment-1143371873
> 给glibc报bug的方案，我再看看 查了一些资料。目前找到的比较充分的讨论是LLVM社区的这个讨论：[[llvm-dev] [RFC] Coroutine and pthread_self](https://lists.llvm.org/pipermail/llvm-dev/2020-November/146766.html) 相关Issue：https://github.com/llvm/llvm-project/issues/47177 讨论中提到的一些问题： 1. [gcc关于函数的`const` attribute的说明](https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html)，并没有写清楚是否是在 *同一线程下* 执行结果相同，在实践中，却被广泛地当成 *同一线程下* 执行结果相同来处理。比如基础库中存在大量将返回tls变量地址的函数定义为`const`的情况，而编译器也默认只在同一个函数调用内将多次`const`函数调用进行合并。有人[在gcc社区要求澄清](https://gcc.gnu.org/legacy-ml/gcc/2015-09/msg00354.html)，但是没有得到明确的答复。 2. 上述实践在过去没有问题，因为在同一个函数中的代码总是在同一个线程中执行。但是协程的出现打破了这种情况（无论是c++20的协程还是类似bthread的这种协程），同一个函数中的代码可能会被协程切换到另一个线程下执行。 讨论的几种解决方案： 1. 修改pthread_self()等函数的声明。但是，这个问题在于要改很多基础库。 2. 编译器识别当前函数是否存在协程环境（如co_await关键字），如果存在，则放弃某些优化。这个需要修改很多个优化器，并且会给将来新增的优化器带来负担。并且如何判断协程环境也是个困难（bthread调用并没有co_await这样的标志）。 3. 新增一个编译器开关来指定是否支持协程安全，如果开启这个开关，则对tls变量和`const`函数进行特殊处理以确保在协程环境下运行正确。实际上，MSVC已经提供了[这样的开关](https://docs.microsoft.com/en-us/cpp/build/reference/gt-support-fiber-safe-thread-local-storage?view=msvc-160)。个人认为这个方案是比较理想的方案。 目前，LLVM社区有一些PR在尝试解决这个问题： * [Fix TLS and Coroutine](https://reviews.llvm.org/D92661) * [Drop const attribute on pthread_self when coroutine is enabled](https://reviews.llvm.org/D92662) 其它相关讨论： * [Disabling TLS address caching to help QEMU on GNU/Linux](https://www.mail-archive.com/[email protected]/msg96208.html) * [Why pthread_self is marked with attribute(const)?](https://stackoverflow.com/questions/36876996/why-pthread-self-is-marked-with-attributeconst) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
