多线程 C/C++变量无缓存 (Linux)

发布于 11-30 22:38 字数 268 浏览 1 评论 0原文

我使用 2 个 pthread,其中一个线程“通知”另一个线程发生事件,为此有一个变量(普通整数),由第二个线程设置。

这是可行的,但我的问题是,是否有可能第一个(读取)线程没有立即看到更新,这意味着缓存没有直接更新?如果是这样,有没有办法阻止这种行为,例如java中的 volatile 关键字?

(事件发生的频率大约在微秒范围内,因此或多或少需要强制立即更新)。

/编辑:第二个问题:是否可以强制将变量保存在线程 1 所在的核心的缓存中,因为该变量一直在读取它。 ?

I use 2 pthreads, where one thread "notifies" the other one of an event, and for that there is a variable ( normal integer ), which is set by the second thread.

This works, but my question is, is it possible that the update is not seen immediately by the first (reading) thread, meaning the cache is not updated directly? And if so, is there a way to prevent this behaviour, e.g. like the volatile keyword in java?

(the frequency which the event occurs is approximately in microsecond range, so more or less immediate update needs to be enforced).

/edit: 2nd question: is it possible to enforce that the variable is hold in the cache of the core where thread 1 is, since this one is reading it all the time. ?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

世俗缘2024-12-07 22:38:36

在我看来,您应该使用 pthread 条件变量作为信号机制。这可以解决您描述的所有问题。

It sounds to me as though you should be using a pthread condition variable as your signaling mechanism. This takes care of all the issues you describe.

何以心动2024-12-07 22:38:36

它可能不会立即被其他处理器看到,但这并不是因为缓存一致性。可见性的最大问题是由于处理器的乱序执行方案或由于编译器在优化时重新排序指令。

为了避免这两个问题,你必须使用 内存 障碍。我相信大多数 pthread 原语都是天然的内存屏障,这意味着您不应期望加载或存储移动到锁定和解锁调用形成的边界之外。 volatile 关键字还可用于禁用某类编译器优化,这些优化在执行无锁算法时很有用,但它不能替代内存屏障。

话虽这么说,我建议您不要手动执行此操作,并且无锁算法存在很多缺陷。把这些头痛的事情留给图书馆作家应该会让你成为一个更快乐的露营者(除非你像我一样并且喜欢头痛:))。所以我最后的建议是忽略我所说的一切并使用弗罗马诺夫或大卫赫夫曼的建议。

It may not be immediately visible by the other processors but not because of cache coherence. The biggest problems of visibility will be due to your processor's out-of-order execution schemes or due to your compiler re-ordering instructions while optimizing.

In order to avoid both these problems, you have to use memory barriers. I believe that most pthread primitives are natural memory barriers which means that you shouldn't expect loads or stores to be moved beyond the boundaries formed by the lock and unlock calls. The volatile keyword can also be useful to disable a certain class of compiler optimizations that can be useful when doing lock-free algorithms but it's not a substitute for memory barriers.

That being said, I recommend you don't do this manually and there are quite a few pitfalls associated with lock-free algorithms. Leaving these headaches to library writters should make you a happier camper (unless you're like me and you love headaches :) ). So my final recomendation is to ignore everything I said and use what vromanov or David Heffman suggested.

御守2024-12-07 22:38:36

将信号从一个线程传递到另一个线程的最合适方法应该是使用运行时库的信号机制,例如互斥体、条件变量、信号量等。

如果这些开销太高,我的第一个想法就是程序的结构有问题。如果事实证明这确实是瓶颈,并且重组程序不合适,那么我将使用编译器或合适的库提供的原子操作。

使用普通的 int 变量,甚至是 volatile 限定的变量很容易出错,除非编译器保证它们具有适当的语义。例如,MSVC 对普通加载和存储到 易失性 变量的原子性和排序约束做出了特殊保证,但 gcc 没有。

The most appropriate way to pass a signal from one thread to another should be to use the runtime library's signalling mechanisms, such as mutexes, condition variables, semaphores, and so forth.

If these have too high an overhead, my first thought would be that there was something wrong with the structure of the program. If it turned out that this really was the bottleneck, and restructuring the program was inappropriate, then I would use atomic operations provided by the compiler or a suitable library.

Using plain int variables, or even volatile-qualified ones is error prone, unless the compiler guarantees they have the appropriate semantics. e.g. MSVC makes particular guarantees about the atomicity and ordering constraints of plain loads and stores to volatile variables, but gcc does not.

几味少女2024-12-07 22:38:36

使用原子变量的更好方法。作为示例,您可以使用 libatomic。易失性关键字还不够。

Better way to use atomic variables. For sample you can use libatomic. volatile keyword not enough.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文