InterlockedIncrement 与 ++
InterlockedIncrement 如何工作？
只关心多处理器系统吗？
它有什么作用，禁用所有处理器的中断？
How does InterlockedIncrement work?
Is the concern only on multi-processor systems?
What does it do, disable interrupts across all processors?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
InterlockedIncrement 的工作原理是使用机器级指令以原子方式递增和存储值。这意味着在此过程中不能对值和存储位置执行任何操作。
任何时候多个线程或进程或访问相同的值都是值得关注的。因此，多线程应用程序中的共享变量，或者多个进程的共享内存。
我不相信该指令会禁用中断，至少在 x86 类型的硬件上是这样。
InterlockedIncrement works by using machine level instructions to increment and store a value in an atomic manner. Meaning no operation can be performed on the value and the storage location during the process.
It is of concern any time multiple threads or processes or accessing the same value. So a shared variable in a multi-threaded application, or shared memory for multiple processes.
I don't believe the instruction disables interrupts, at least on x86 type hardware.
jcopenha 是正确的，但我只是想回答“仅关注多处理器系统吗？”
我不知道您使用的是哪种
Interlocked。如果你指的是 c++ ，那么在单核上，如果 x 不大于你的“位数”，你“应该”安全地执行“++x”。我写“应该”，因为编译器可以在函数中以某种奇怪的方式优化它 - 例如，在完全不同的地方将两个“++x”更改为正常的“add ...,2”以及一些多线程逻辑可能会因此而失败。在多核上，即使是 32 位 x 上的 ++x 也会产生奇怪的效果（指令可以是“inc mem”或“lock inc mem”，当您从两个 cpu 中增加一个未锁定的 mem 地址时，您得到奇怪的结果）。如果你的 x 的“位数”高于你的 cpu，那么你需要在任何多线程代码中互锁 - 无论它是单核还是多核，因为该指令无论如何都必须编译成两个 asm 代码和上下文切换之间可能发生。 （不过，这可以通过 RCU 修复）
在 .NET 中，情况基本相同，但您重载了 Increment，而不是 Interlocked... 和 Interlocked...64。
所以是的 - 每当你编写多线程的东西（即使是在单核上）时，只需使用共享内存上的互锁增量即可。在这里，不值得尝试比机器“更聪明”。
jcopenha is correct, but I just wanted to answer to "Is the concern only on multi-processor systems?"
I don't know which
Interlockedare you using. If you mean the c++ one, then on a single-core you "should be" safe to do "++x" if x is not bigger than your "bitness". I write "should be", because compiler can optimise it in some strange way in the function - for example change two "++x" into a normal "add ...,2" in a completely different place and some of your multithreading logic may fail because of that. On a multicore, even ++x on a 32-bit x can have weird effects (the instruction can be "inc mem", or "lock inc mem" and when you increment one mem address from two cpus when it's not locked, you get strange results).If the "bitness" of your x is higher than your cpu, then you need interlocked in any multithreaded code - doesn't matter if it's single- or multicore, because that instruction has to be compiled into two asm codes anyways and the context switch might happen in between. (this can be fixed with RCU though)
In .NET it's basically the same story, but you have overloaded Increment, instead of Interlocked... and Interlocked...64.
So yeah - whenever you write multithreaded stuff (even on a single-core), just use the interlocked increments on shared memory. It's not worth trying to be "smarter" than machine here.
如果您关心性能，InterlockIncrement 绝对是最佳选择：InterlockIncrement 递增指定变量并存储结果，因为传递变量的原子操作 (MSDN) 是通过引用传递的 (Interlocked.Increment(refincrement))。对于 ++，值通过地址传递，导致每次调用指令时都会在内存中进行往返。
InterlockIncrement is definitely the way to go if you are concerned by performance: InterlockIncrement increments a specified variable and stores the result, as an atomic operation(MSDN) passing the variable is passed by reference(Interlocked.Increment(ref increment)). With ++, the value is passed by address causing an round trip in memory every time the instruction is called.