问题标签 [interlocked-increment]

使用 32 位和 64 位架构通用的 C++ InterlockedIncrement 功能的最佳方式是什么？（有分离的功能）

有没有比使用#if _W64预处理器命令更好的方法？

我有一个这样定义的地图。

我像这样使用它。

我看到了这个，我明白 find 是线程安全的。但我在想 InterlockedIncrement( &itr->second) 也会是线程安全的吗？上面的代码线程安全吗？在多线程环境中，此映射中绝对没有插入。

（这是重复：如何正确读取 Interlocked.Increment'ed int 字段？但是，在阅读了答案和评论后，我仍然不确定正确的答案。）

有些代码我不拥有，也无法更改为使用在几个不同线程中递增 int 计数器 (numberOfUpdates) 的锁。所有调用都使用：

我想在我的代码中阅读 numberOfUpdates 。现在，由于这是一个 int，我知道它不能撕裂。但是，确保我获得最新价值的最佳方式是什么？看来我的选择是：

或者

两者都可以工作吗（在提供最新价值的意义上，无论优化、重新排序、缓存等如何）？一个比另一个更受欢迎吗？有没有更好的第三种选择？

我需要使用 Interlocked 类处理我的 C# 应用程序中的锁。我有这样的代码：

当我想在 Interlocked 类上替换 ThreadProc 中的锁时，例如：

我收到此错误：

这个错误：错误 CS1503: Argument #1' cannot convert ulong to ref int' (CS1503) (projectx)

如何解决？

最近我从 VB 转到 C#，所以我经常使用 C# 到 VB.NET 的转换器来了解语法差异。在将下一个方法转移到 VB 时，我注意到一件有趣的事情。

C#原代码：

VB.NET 结果：

C#的++操作符被替换为System.Threading.Interlocked.Increment 是否意味着++如果在foreach循环中使用不是线程安全的操作符成为线程安全的？它是一种语法糖吗？如果这是真的，那为什么转换器放在Interlocked.IncrementVB版本中呢？我认为 C# 和 VB 中的 foreach 工作方式完全相同。或者它只是一个转换器“保险”？

我正在尝试将 32 位应用程序移植到 64 位，但遇到了一些互锁功能的问题，即：InterlockedIncrement64、Decrement64、Exchange64和.CompareExchange64ExchangeAdd64

错误：

错误 LNK2001：未解析的外部符号“_InterlockedExchange64”C:\path_to_object_file\myclass.obj

我已经搜索了错误并找到了一些线程，但似乎没有一个有效。（例如看到这个）

我检查了 kernel32.lib 和 psapi.lib 的位置（/VERBOSE_LIB），上面链接的解决方案没有帮助（在 Project->Linker->Additional Dependencies 中给出 psapi.lib 的完整路径）。

我还检查了 Vc++ 目录，尤其是库目录是否确实在 Win32-Version 和 x64 之间发生了变化，这是他们应该做的。

提前感谢您的帮助。

为另一个问题写一个答案，一些有趣的事情出现了，现在我无法理解Interlocked.Increment(ref long value)在 32 位系统上是如何工作的。让我解释。

在为 32 位环境编译时， NativeInterlockedIncrement64现在不可用，好吧，这是有道理的，因为在 .NET 中，您无法根据需要对齐内存，并且可能会从托管调用它，然后他们将其删除。

在 .NET 中，我们可以Interlocked.Increment()使用对 64 位变量的引用进行调用，我们仍然没有对其对齐的任何约束（例如在结构中，我们也可以使用FieldOffsetand StructLayout）但是文档没有提到任何限制（AFAIK ）。这很神奇，它有效！

Hans Passant 指出，这Interlocked.Increment()是 JIT 编译器识别的一种特殊方法，它将发出对 COMInterlocked::ExchangeAdd64()的调用，然后调用FastInterlockExchangeAddLong ，这是InterlockedExchangeAdd64的宏，与InterlockedIncrement64具有相同的限制。

现在我很困惑。

忘记一秒钟的托管环境，回到原生环境。为什么InterlockedIncrement64不能工作，但InterlockedExchangeAdd64可以？InterlockedIncrement64是一个宏，如果内在函数不可用并且InterlockedExchangeAdd64可以工作，那么它可以作为对InterlockedExchangeAdd64...的调用来实现

让我们回到托管：如何在 32 位系统上实现原子 64 位增量？我想句子“这个函数相对于对其他联锁函数的调用是原子的”很重要，但我仍然没有看到任何代码（感谢 Hans 指出更深层次的实现）来做到这一点。InterlockedExchangedAdd64当内在函数不可用时，让我们从 WinBase.h 中选择实现：

读/写怎么能是原子的？

我们有一个方法可以维护应用程序中所有事件的全局序列索引。由于它是网站，因此预计会有这种方法线程安全。线程安全的实现如下：

但是我们注意到，在一些不重负载下，系统中会出现重复索引。简单的测试表明，对于 100000 次迭代，大约有 1500 个重复项。

这可以通过以下实现来解决：

但是，我不清楚，为什么第一次实施没有奏效。任何人都可以帮我描述在这种情况下发生了什么吗？

我知道 int 在内存中不会有固定的位置，所以它根本不能那样工作。但是完全相同的代码部分将使用不同的名称、参数等同时运行

我需要传递一个“名称”字符串，然后以某种方式增加我的 int 数组中的一个项目。

Dictionary<string, int> intStats = new Dictionary<string, int>();

该字典根据作为字典字符串键提供的“名称”存储所有统计信息。

而且由于我使用了很多多线程，我希望保持 int 计数尽可能同步。这就是为什么我试图使用Interlocked.Increment(ref intStats[theName]); 但不幸的是这不起作用。

有没有适合我的情况的替代方案？

我正在尝试重构我的项目，现在我正在尝试寻找提高应用程序性能的最佳方法。

问题 1. SpinLock vs Interlocked

要创建计数器，哪种方式性能更好。

或者

如果我们需要增加另一个计数器，比如counter2，我们应该声明另一个SpinLock对象吗？还是足以使用另一个boolean对象？

问题2.处理嵌套任务或更好的替换

在我的应用程序的当前版本中，我使用了任务，将每个新任务添加到数组中，然后使用Task.WaitAll()

经过大量研究，我发现 usingParallel.ForEach具有更好的性能，但是如何控制当前线程的数量？我知道我可以MaxDegreeOfParallelism在ParallelOptions参数中指定a，但问题出在这里，每次crawl(url)方法运行时，它只会创建另一个有限数量的线程，我的意思是如果我设置MaxDegree为10，每次crawl(url)运行，都会创建另一个+10，是吗？对吧？，那我该如何防止呢？我应该使用信号量和线程而不是并行吗？还是有更好的方法？

问题 3. 当所有作业（和嵌套作业）完成时通知。

我的最后一个问题是，我如何才能了解我的所有工作何时完成？