我有一个C++ 11程序,它执行一些计算并使用a std::unordered_map来缓存那些计算的结果.该程序使用多个线程,并使用共享unordered_map来存储和共享计算结果.
基于我对unordered_mapSTL容器规范的读取以及unordered_map线程安全性,似乎unordered_map多个线程共享的一个线程可以一次处理一个线程,但一次只能处理许多读者.
因此,我使用a std::mutex将我的insert()调用包装到地图中,因此一次最多只插入一个线程.
但是,我的find()调用没有互斥,因为从我的阅读来看,似乎许多线程应该能够立即读取.但是,我偶尔会得到数据竞赛(由TSAN检测到),在SEGV中表现出来.这些数据清楚地赛点的insert(),并find()调用我上面提到的.
当我find()用互斥锁包装调用时,问题就消失了.但是,我不想序列化并发读取,因为我试图尽可能快地使这个程序.(仅供参考:我正在使用gcc 5.4.)
为什么会这样？我对并发保证的理解std::unordered_map不正确吗？
我正在尝试将应用程序升级到C ++ 17并收到以下编译器错误：
error: ‘__BEGIN_NAMESPACE_STD’ does not name a type
我正在使用gcc（GCC）8.2.0并使用以下命令进行编译：
g++ -std=c++17 variant.cpp -o variant
这是一个小测试程序：
#include <iostream>
#include <variant>
using v_t = std::variant<int, double>;
int main(int argc, char const* argv[]) {
v_t foo = 5;
printf("foo contains %d\n", *std::get_if<int>(&foo));
std::cout << "Success" << std::endl;
return 0;
}
这是我得到的错误（如下）。请注意，如何在stdlib.h中启用__BEGIN_NAMESPACE_STD讨论了类似的问题，但是建议的解决方案（包括C ++头文件，而不是诸如stdlib.h之类的C头文件）是我已经在做的事情。
我能够在OSX便携式计算机上编译此代码，可能是因为默认情况下安装了更新的libc。但是，当我在Linux机器上运行时，出现这些错误。在Linux机器上，我正在使用以下链接器/ glibc版本：ldd (Ubuntu EGLIBC 2.19-0ubuntu6.14) 2.19
我正在继续调试，但是希望有朝正确方向发展的指针。
In file included from /toolchains/gcc-8.2.0/include/c++/8.2.0/cstdlib:75,
from /toolchains/gcc-8.2.0/include/c++/8.2.0/ext/string_conversions.h:41,
from /toolchains/gcc-8.2.0/include/c++/8.2.0/bits/basic_string.h:6391,
from /toolchains/gcc-8.2.0/include/c++/8.2.0/string:52,
from /toolchains/gcc-8.2.0/include/c++/8.2.0/bits/locale_classes.h:40,
from /toolchains/gcc-8.2.0/include/c++/8.2.0/bits/ios_base.h:41,
from /toolchains/gcc-8.2.0/include/c++/8.2.0/ios:42,
from /toolchains/gcc-8.2.0/include/c++/8.2.0/ostream:38, …我正在编写一个C++ 14程序来从文件中加载文本字符串,对它们进行一些计算,然后写回另一个文件.我正在使用Linux,文件相对较大(O(10 ^ 6行)).我的典型方法是使用旧的C getline和sscanf实用程序来读取和解析输入,以及fprintf(FILE*, …)编写输出文件.这是有效的,但我想知道是否有更好的方法来实现高性能和通常推荐的方法与我正在使用的现代C++标准.我听说这iostream很慢; 如果这是真的,我想知道是否有更推荐的方法.
更新:为了澄清一下用例:对于输入文件的每一行,我将进行一些文本操作(数据清理等).每条线都是独立的.因此,加载整个输入文件(或者至少是它的大块),逐行处理,然后编写它,似乎最有意义.对此的理想抽象是获取读入缓冲区的迭代器,每行都是一个条目.有没有推荐的方法用std :: ifstream做到这一点？