当 read_json 在多个线程中使用而不与 boost.thread 库链接时，我们是不是可以始终使用 BOOST_SPIRIT_THREADSAFE 标志？

Posted 2023-02-21

【中文标题】当 read_json 在多个线程中使用而不与 boost.thread 库链接时，我们是不是可以始终使用 BOOST_SPIRIT_THREADSAFE 标志？

【英文标题】：Can we use BOOST_SPIRIT_THREADSAFE flag always when read_json is used in multiple threads without linking with boost.thread libraries?当 read_json 在多个线程中使用而不与 boost.thread 库链接时，我们是否可以始终使用 BOOST_SPIRIT_THREADSAFE 标志？

【发布时间】：2016-03-14 21:35:41

【问题描述】：

我们在项目中使用了 boost。我们没有链接任何 boost 库，但我们包含 boost 头文件，如 boost/property_tree/ptree.hpp。

我们正在从多个线程（不是 boost 线程而是 posix 线程）调用 read_json，并且我们在 read_json() 函数处遇到了崩溃。现在我们在包含头文件之前包含了 BOOST_SPIRIT_THREADSAFE，因为 boost json 解析器不是线程安全的，而且一切正常。但我们的审阅者不接受此更改，他指向以下链接

http://www.boost.org/doc/libs/1_60_0/libs/spirit/classic/doc/grammar.html

正如本页提到的“另一方面，如果语法 旨在用于多线程代码，然后我们应该定义 BOOST_SPIRIT_THREADSAFE 在包含任何精神头文件之前。在这 如果还需要链接到 Boost.Threads"

但是我们真的需要链接 Boost.Threads 库吗，因为我们没有使用 boost 线程，而且我的理解是 boost 线程内部将使用 Linux 平台上的 posix 线程。如果我错了，谁能告诉我。

【参考方案1】：

审阅者正在链接到 Classic Spirit 的“1.60.0”文档。

Spirit Classic 已经过时了十年或更长时间。

此外，Boost Property Tree 重写了它的解析器：它在 1.60.0 中根本不使用 Spirit。某些版本就是这种情况。

请注意，在 main 入口点之外使用属性树时可能会出现问题，请参阅例如：

boost::property_tree::info_parser breaks on spaces in value

【讨论】：

这意味着如果我们使用旧的 bo​​ost 代码，我们仍然需要使用那个标志。我无法理解的一件事是，如果我们在不同的进程中使用 read_json，为什么我们需要这个标志，因为进程地址完全不同。