避免不使用多线程时std :: mutex的成本? [英] avoid cost of std::mutex when not multi-threading?
问题描述
假设我有一个可能生成或未生成多个线程的应用程序. 保护需要按条件与std :: mutex进行同步的操作是否值得，如下所示，还是这种锁如此便宜以至于单线程处理都没有关系?
Suppose I have an application that may or may not have spawned multiple threads. Is it worth it to protect operations that need synchronization conditionally with a std::mutex as shown below, or is the lock so cheap that it does not matter when single-threading?
#include <atomic>
#include <mutex>
std::atomic<bool> more_than_one_thread_active{false};
void operation_requiring_synchronization() {
//...
}
void call_operation_requiring_synchronization() {
if (more_than_one_thread_active) {
static std::mutex mutex;
std::lock_guard<std::mutex> lock(mutex);
operation_requiring_synchronization();
} else {
operation_requiring_synchronization();
}
}
修改
感谢所有回答和评论的人，非常有趣的讨论.
Thanks to all who have answered and commented, very interesting discussion.
一些澄清:
应用程序处理输入的大块，并为每个大块确定将以单线程，并行还是并行的方式对其进行处理.不需要多线程并不是不可能.
The application processes chunks of input, and for each chunk decides if it will be processed in a single-threaded or parallel or otherwise concurrent fashion. It is not unlikely that no multi-threading will be needed.
operation_requiring_synchronization()通常由一些插入到全局标准容器中的插入物组成.
The operation_requiring_synchronization() will typically consist of a few inserts into global standard containers.
当应用程序独立于平台且在各种平台和编译器(过去，现在和将来)下应能很好地运行时，剖析当然是困难的.
Profiling is, of course, difficult when the application is platform-independent and should perform well under a variety of platforms and compilers (past, present and future).
根据到目前为止的讨论，我倾向于认为优化是值得的.
Based on the discussion so far, I tend to think that the optimization is worth it.
我还认为std::atomic<bool> more_than_one_thread_active应该应该更改为非原子bool multithreading_has_been_initialized.最初的想法是能够在除主线程之外的所有线程都处于休眠状态时再次关闭该标志，但我知道这可能容易出错.
I also think the std::atomic<bool> more_than_one_thread_active should probably be changed to a non-atomic bool multithreading_has_been_initialized. The original idea was to be able to turn the flag off again when all threads other than the main one are dormant but I see how this could be error-prone.
将显式条件抽象到自定义的lock_guard中是一个好主意(并有助于将来的设计更改，包括在认为优化不值得的情况下简单地返回到std :: lock_guard).
Abstracting the explicit conditional away into a customized lock_guard is a good idea (and facilitates future changes of the design, including simply reverting back to std::lock_guard if the optimization is not deemed worth it).
推荐答案
通常，如果优化会影响代码的设计或组织，则不应在您的特定用例中没有明显需求的情况下执行优化.这是因为以后很难执行这类算法优化.点微优化总是可以在以后添加，出于以下几个原因，应在需要时避免使用它:
Generally, optimizations should not be performed in the absence of demonstrated need in your specific use case if they affect the design or organization of code. That's because these kinds of algorithmic optimizations can be very difficult to perform later. Point micro-optimizations can always be added later and should be avoided prior to need for several reasons:
-
如果您对典型用例有误，那么它们实际上会使性能变差.
If you guess wrong about the typical use case, they can actually make performance worse.
它们可以使代码更难以调试和维护.
They can make code harder to debug and maintain.
即使您对用例的猜测正确，它们也可能使新平台的性能变差.例如，在过去八年中，互斥锁的价格便宜了一个数量级.今天有意义的折衷方案明天可能就没有意义.
Even if you guess right about the use case, they can make performance worse on new platforms. For example, mutex acquisition has gotten more than an order of magnitude cheaper in the last eight years. Tradeoffs that make sense today might not make sense tomorrow.
您可以浪费时间在不必要的事情上，更糟糕的是，您可能会浪费时间进行其他优化.没有大量经验，很难预测代码中的实际瓶颈在哪里，甚至专家在进行概要分析时也会经常感到惊讶.
You can wind up wasting time on things that are unnecessary, and worse you can waste time that needed to go into other optimizations. Without enormous amounts of experience, it's very difficult to predict where the actual bottlenecks in your code will be, and even experts are frequently surprised when they actually profile.
这是经典的点微优化，因此只有在性能分析显示出某些可能的好处时才应该这样做.
This is a classic point micro-optimization, so it should be done only if profiling demonstrates some likely benefit.
这篇关于避免不使用多线程时std :: mutex的成本?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
