开发平台(Platform): (Ex: VC++, GCC, Linux, ...)
Linux
额外使用到的函数库(Library Used): (Ex: OpenGL, ...)
google/sparsehash.h
问题(Question)：
大家好。
我的某个程式要开30个threads同时执行，
但这30个核心都要共用同一个Google Sparse Hash Map，
所以我喂给这些threads的是某个Hash Table的pointer，
因此它们会共用这张Hash Table。
问题来了，这样执行起来往往会造成core dumped，
一开始我用#pragma omp critical
将写入这张Hash Table的程式码(只有一行)包起来，
执行起来居然会Core dumped！
后来改成将每个读取或写入到这张table的程式码都包起来，
但这显然不是个好办法，因为30核的效果会大打折扣，趋近于单核的速度。
后来改成针对不同的key值，
用omp_test_lock和omp_unset_lock去包住，
区别不同的critical section。
却还是会造成core dumped！
所以开始怀疑是不是Google Sparse Hash不支援以key区分不同的执行绪的功能？
能解决这奇怪问题的我愿意给500P
喂入的资料(Input)：
预期的正确结果(Expected Output)：
错误结果(Wrong Output)：
程式码(Code)：(请善用置底文网页, 记得排版)
补充说明(Supplement)：

用储列排队写入?

你的 omp_test_lock 没 lock 到的话是怎么处理的?..... 既然如此何苦用 test，用 omp_set_lock 不就好了

可考虑改用 Intel TBB 的 tbb::concurrent_hash_map

..... 若已经被 lock，omp_set_lock() 会 block 住，等待此 lock 被其他人释放，才取得 lock 继续。所以切记，一个 thread 千万不可在手上持有 lock 时再去 set 一次，这样就变成永远解不开的 dead lock 了基本上 omp_set_lock 和你原本的作法没有多少差别会 core dump 的还是会 core dump我那样问只是怀疑你在 omp_test_lock 没锁到时处理有错