我试图让一个C++ API（用于Linux和Solaris）具有线程安全性，以便其函数可以从不同的线程中调用而不会破坏内部数据结构。在我的当前方法中，我使用pthread mutexes来保护对成员变量的所有访问。这意味着一个简单的getter函数现在会锁定和解锁互斥锁，并且我担心这会带来一定的开销，特别是当API大多数情况下将被用于单线程应用程序时，任何互斥锁定似乎都是纯粹的开销。
因此，我想问：
所有现代线程实现都可以完全在用户空间中处理无争用的互斥锁（只需要几条机器指令）- 仅在存在争用时，库才必须调用内核。
另一个要考虑的问题是，如果应用程序没有显式链接到pthread库（因为它是单线程应用程序），则只会获得虚拟的pthread函数（根本不会进行任何锁定）- 仅当应用程序是多线程的（并链接到pthread库）时，才会使用完整的pthread函数。
最后，正如其他人已经指出的那样，对于类似isActive这样的getter方法使用互斥锁保护是没有意义的- 一旦调用者有机会查看返回值，该值可能已经被更改了（因为互斥锁只在getter方法内部被锁定）。
"互斥锁需要进行操作系统上下文切换，这是相当昂贵的。"
更多信息请参见： Futex
这可能有点偏题，但你似乎对线程还不太熟悉——首先，只在线程可能重叠的地方进行锁定。然后，尽量减少这些地方。此外，不要试图锁定每个方法，考虑线程在对象上的整体操作，并将其作为单个调用进行锁定。尽量将锁定置于最高层（这样可以提高效率并/有助于/避免死锁）。但是锁定不能“组合”，您必须至少通过线程所在的位置和重叠来进行代码的跨组织。
#ifdef BUILD_SINGLE_THREAD
inline void lock () {}
inline void unlock () {}
#else
inline void lock () { doSomethingReal(); }
inline void unlock () { doSomethingElseReal(); }
#endif
我对使用 pthred_mutex_lock/unlock 的开销很好奇。我遇到了这样一种情况，需要在不使用互斥锁的情况下复制1500-65K字节，或者使用互斥锁并进行单个写入指向所需数据的指针。
我编写了一个简短的循环来测试每个选项。
gettimeofday(&starttime, NULL)
COPY DATA
gettimeofday(&endtime, NULL)
timersub(&endtime, &starttime, &timediff)
print out timediff data
ettimeofday(&starttime, NULL)
pthread_mutex_lock(&mutex);
gettimeofday(&endtime, NULL)
pthread_mutex_unlock(&mutex);
timersub(&endtime, &starttime, &timediff)
print out timediff data
pthread_mutex_lock()/_unlcok()对。而且这并不是一个高端系统。但这个时间显然包括了缓存和用户空间处理的好处。 - class stacker一个次优但简单的方法是在您的互斥锁上放置宏，然后有一个编译器/Makefile选项来启用/禁用线程。
例如：
#ifdef THREAD_ENABLED
#define pthread_mutex_lock(x) ... //actual mutex call
#endif
#ifndef THREAD_ENABLED
#define pthread_mutex_lock(x) ... //do nothing
#endif
然后在编译时执行gcc -DTHREAD_ENABLED以启用线程。
再次强调，我不建议在任何大型项目中使用此方法。但如果你只是想要一些相对简单的东西，那么可以考虑使用。
pthread.h之后使用#define pthread_mutex_lock会导致未定义的行为（如果可能的话，您可以完全跳过pthread.h）。 - R.. GitHub STOP HELPING ICE
- 当前API存在类似OpenGL的限制：对象只能在创建它们的线程中使用/操作。我想要消除这个限制。
- “访问器”方法的观点很好 - 我会记住这一点，用于未来的API，但当前的API无法以这种方式更改。
- 只有少数公共方法；因此，我将在所有这些方法中添加锁定（其中大多数都是相当高级的）。
- 是的，我是新手多线程 :-)
- oliver