只读存储器访问线程安全 [英] Thread-safety of read-only memory access

问题描述

我实现了在C巴恩斯必胜客重力的算法如下：

I've implemented the Barnes-Hut gravity algorithm in C as follows:

1. 构建集群星树。


2. 对于每一个明星，遍历树并从每个适用的节点施加引力。


3. 更新速度星和立场。

第2阶段是最昂贵的阶段，所以在平行除以该组分实施。例如。 1000星和2个线程，我有一个线程处理第500星星和第二个线程处理500次。

Stage 2 is the most expensive stage, and so is implemented in parallel by dividing the set of stars. E.g. with 1000 stars and 2 threads, I have one thread processing the first 500 stars and the second thread processing the second 500.

在实践中，这工作的：它由约30％用双核机上两个线程速度的计算，相对于非线程版本。此外，它产生相同的数字结果作为原非线程版本。

In practice this works: it speeds the computation by about 30% with two threads on a two-core machine, compared to the non-threaded version. Additionally, it yields the same numerical results as the original non-threaded version.

我担心的是，这两个线程正在访问相同的资源（即树）同时进行。我还没有添加到线程工人任何同步，所以很可能，他们将尝试从在某一点相同的位置读取。虽然进入树是严格只读的，我不是100％肯定它是安全的。当我测试过，但我知道这是不正确的保证它的工作！

My concern is that the two threads are accessing the same resource (namely, the tree) simultaneously. I have not added any synchronisation to the thread workers, so it's likely they will attempt to read from the same location at some point. Although access to the tree is strictly read-only I am not 100% sure it's safe. It has worked when I've tested it but I know this is no guarantee of correctness!

的问题的

• 请我需要树的私有副本的每个线程？


• 即使是安全的，从多个线程访问相同的内存有性能问题？

更新基准为好奇的结果：

机：英特尔凌动N270 CPU @ 1.60GHz的，CPU兆赫800，缓存大小512 KB

Machine: Intel Atom CPU N270 @ 1.60GHz, cpu MHz 800, cache size 512 KB

Threads      real      user      sys
      0    69.056    67.324    1.720
      1    76.821    66.268    5.296
      2    50.272    63.608   10.585
      3    55.510    55.907   13.169
      4    49.789    43.291   29.838
      5    54.245    41.423   31.094

0表示没有线程可言; 1及以上手段产卵，很多工作线程和主线程等待他们。我不会指望多大的改善超出2个线程任何东西，因为它完全是CPU绑定，并且那是多少个核心也有。有趣的是，一个奇怪的线程数比偶数稍差。

0 means no threading at all; 1 and above means spawn that many worker threads and for the main thread to wait for them. I would not expect much of an improvement for anything beyond 2 threads, since it's entirely CPU bound and that's how many cores there are. It's interesting that an odd number of threads is slightly worse than an even number.

看着 SYS 这是显而易见的是有一个与线程制作成本。目前，它使线程的每一帧（所以N * 1000螺纹创作）。这是很容易的程序（在此上午在火车上我的15分钟）。我需要去思考一些关于如何重用线程...

Looking at sys it's apparent that there's a cost with making threads. Currently it's making the threads for each frame (so N*1000 thread creations). This was easy to program (during my 15 minutes on the train this morning). I'll need to think a bit about how to reuse threads...

更新＃2 我将它使用一个线程池，有两个障碍同步。这有没有明显的性能优势重新创建线程每一帧。

Update #2 I've made it use a pool of threads, synchronised with two barriers. This has no noticeable performance advantage over recreating the threads each frame.

推荐答案

您没有指定您的数据是如何组织的，但在从多个线程一般阅读记忆同时是安全的，不会引入任何性能问题。你只得到的问题，如果有人写。

You don't specify how your data is structured, but in general reading memory from multiple threads simultaneously is safe and does not introduce any performance issues. You only get problems if someone is writing.

有趣的是，你说你只得到30％的速度提升了两个线程。如果你有一个空闲的机器，两个或两个以上的CPU，只有只读共享数据（即不同步）我希望看到更接近50％的速度提升。这表明，您的操作实际上完成如此之快，在创建线程的开销成为你的数字显著。你是一个超线程CPU上运行？

It is interesting that you say you're only getting 30% speedup out of two threads. If you have an otherwise idle machine, two or more CPUs and only readonly shared data (i.e. no synchronization) I would expect to see much closer to 50% speed improvement. This suggests that your operation is actually completing so quickly that the overhead of creating the thread is becoming significant in your numbers. Are you running on a hyperthreaded CPU?

这篇关于只读存储器访问线程安全的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！