如何测试和测试互斥量实现

如标题所述：如何正确测试和基准化c ++中互斥锁的不同实现？

本质上，我为在2核，armv7上运行的项目编写了自己的std :: mutex类似类，目的是在无争议的情况下最大程度地减少开销。现在，我正在考虑在更多地方以及不同的体系结构中使用所说的互斥锁，但是在执行此操作之前，我想确保

• 这实际上是正确的
• 没有任何病理情况比标准的std :: mutex表现差很多。

显然，我写了一些基本的单元测试和微基准测试，一切似乎都可以用，但是在多线程代码中，“似乎可以使用”并不能给我带来很大的安慰。

• 那么，是否有已建立的静态或动态分析技术？
• 为互斥类编写单元测试时，常见的陷阱有哪些？
• 在性能方面应该注意哪些典型的极端情况？

我仅将标准库类型用于实现，其中包括对原子的非顺序一致的加载和存储操作。但是，我主要对实现不可知的建议感兴趣，因为我也想对其他实现使用相同的测试工具。

问题很复杂：

复杂性的一些来源包括：

• 正在进行多少次上下文切换：这非常重要，具体取决于运行这些测试的平台。一些平台比其他平台处理得更好
• 是否以内联方式测试互斥锁的功能。即互斥锁仅在经过优化或可优化的代码中才能表现良好。
• 这些互斥量是为缓存局部性设计的吗？高速缓存未命中会大大降低性能或导致更多上下文切换。输入互斥锁之前和之后。
• 互斥锁本身是否会导致缓存局部性丢失。即互斥量状态数据是动态分配的。
• 这些互斥锁在上下文切换包含在互斥锁中的情况下，能否表现良好？即io，malloc等。
• 如果将内核时间包含在Mutex.ie中（即动态内存分配和取消分配），则互斥锁是否会表现良好。
• 在VM内运行时性能是否保持不变
• 互斥量的破坏或构建是否昂贵，即状态数据位于动态内存中

您的想法非常有趣：可以测试互斥量实现的合规性基准。

不幸的是，据我所知，互斥量实现尚无广为人知的合规性基准。因此，我想您手中有一个非常有趣的问题，即为此类合规性基准创建提案。

而且，由于您参与了基准实施的创建，因此您就是这个人。

如果您允许我提出建议，也许您可​​以从一方面针对线程的POSIX标准着手进行这项研究，然后对并发处理（例如CSP或通信顺序过程）的理论文献进行一些研究。这类论文通常涉及经典的并发问题，例如餐饮哲学家。

我想，实施它们可能是合规性基准中有趣的一部分。