.NET 中何时使用锁与 MemoryBarrier

发布于 2024-08-16 16:32:59 字数 1033 浏览 11 评论 0原文

在 .NET 中,lock 关键字是 Monitor.EnterMonitor.Exit 周围的语法糖,因此您可以说这段代码

lock(locker)
{
  // Do something
}

Monitor.Enter(locker);
try
{
  // Do Something
}
finally
{
  Monitor.Exit(locker);
}

然而.NET框架还包括MemoryBarrier类,它的工作方式类似,

Thread.MemoryBarrier();
//Do something
Thread.MemoryBarrier();

当我想在lock<上使用Thread.MemoryBarrier时,我感到很困惑/code>/监控版本? 线程教程让我更加困惑,其中指出它们的功能相同。

据我所知,明显的区别是不需要锁定对象,我猜想使用Monitor您可以跨线程执行某些操作,其中MemoryBarrier位于单个线程上。

我的直觉告诉我,另一个关键区别是 MemoryBarrier 仅适用于变量,不适用于方法。

最后,这与现有问题 何时在线程安全锁定代码中使用“易失性”或“Thread.MemoryBarrier()”? (C#),因为它重点关注我理解其用法的 volatile 关键字。

In .NET the lock keyword is syntactic sugar around Monitor.Enter and Monitor.Exit, so you could say that this code

lock(locker)
{
  // Do something
}

is the same as

Monitor.Enter(locker);
try
{
  // Do Something
}
finally
{
  Monitor.Exit(locker);
}

However the .NET framework also includes the MemoryBarrier class which works in a similar way

Thread.MemoryBarrier();
//Do something
Thread.MemoryBarrier();

I am confused as when I would want to use Thread.MemoryBarrier over the lock/Monitor version? I am made even more confused by a Threading Tutorial which states they function tthe same.

As far as I can see the visible difference is not needing a locking object, which I guess that using Monitor you could do something across threads where MemoryBarrier is on a single thread.

My gut is telling me that another key difference is MemoryBarrier is for variables only and not for methods.

Lastly this is not related to the existing question When to use ‘volatile’ or ‘Thread.MemoryBarrier()’ in threadsafe locking code? (C#), as that is focusing on the volatile keyword which I understand its usage of.

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

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

发布评论

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

评论(1

你怎么敢 2024-08-23 16:32:59

在我看来,您几乎应该永远使用Thread.MemoryBarrier。这用于无锁代码 - 确保一个线程上所做的更改对另一个线程可见,而不会产生锁的成本。与不同,它控制线程同步。我没有看到 Joe 的教程中他说 MemoryBarrierlock“功能相同”。您能解释一下您是从哪里得到这种印象的吗?

在我看来,低级无锁代码对于除了主要擅长并发的开发人员之外的几乎任何人来说都太困难了。如果我想编写一些无锁代码,我将使用这些开发人员构建的更高级别的构建块(例如 .NET 4.0 中的并行扩展),而不是尝试自己构建。

举个例子,我最近开始了解 易失性 的确切含义,它不是“总是从主内存读取,总是直接写入主内存”。 (我自己的线程教程目前仍然有这样的解释 - 我需要在某些时候修复它。) 比这微妙得多。这意味着我之前使用的易失性一些很可能是不正确的。

In my view you should almost never use Thread.MemoryBarrier. This is used for lock-free code - making sure that changes made on one thread are visible to another without incurring the cost of a lock. It does not control thread synchronization, unlike lock. I don't see where in Joe's tutorial he says that MemoryBarrier "functions the same" as lock. Could you explain where exactly you're getting that impression from?

In my view, low level lock-free code is too difficult for almost anyone other than developers whose main proficiency is concurrency. If I want to write some lock-free code, I'll use higher level building blocks built by those developers (such as Parallel Extensions in .NET 4.0) rather than trying to roll my own.

Just as an example, I recently had my eyes opened to the precise meaning of volatile which isn't "always read from main memory, always write directly to main memory". (My own threading tutorial still has that explanation at the moment - something I need to fix at some point.) It's far more subtle than that. This means that some of my previous uses of volatile may well be incorrect.

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