我发现以下文章： 使用 GCC 提供的原子锁操作替换 pthread_mutex_lock 函数
它指的是 GCC 原子内置。
本文建议使用 GCC 原子内置函数而不是 pthread 同步工具。
这是个好主意吗？
PS。 mysql 帖子显然具有误导性。 原子内置程序无法取代所有 pthread 工具。 例如，锁定要求，如果无法获取锁，则线程必须等待。 换句话说，它要求操作系统等待，因此等待是被动的。 简单的 GCC 内置函数无法做到这一点。
I've found following article: Use GCC-provided atomic lock operations to replace pthread_mutex_lock functions
It refers to GCC Atomic Builtins.
What the article suggest, is to use GCC atomic builtins instead of pthread synchronization tools.
Is this a good idea?
PS. The mysql post is obviously misleading. Atomic Builtins can't replace all pthread tools. For example, the locking requires, that if a lock can't be acquired, a thread has to wait. In other words, it asks the OS to wait, so that the wait is passive. Simple GCC builtin can't do that.
发布评论
评论（5）
如果您想提高性能，原子内置函数是有意义的。 内置函数允许您最大限度地减少互斥体序列化引起的争用。 当您使用互斥体并创建关键会话时，您将序列化对该代码部分的访问； 在性能代码中，您可能希望尝试通过使用特定于线程的数据来避免争用，并且在不可能时使用原子。 最后一种情况是锁定，锁定时，尽量减少持有锁定的时间（使用消息传递和双重检查锁定，尽管有些人声称它不起作用 - 对我有用）。
atomic builtins make sense if you want to improve performance. Builtins allow you to minimize contention caused by the serialization of mutexes. When you use mutexes and create a critical session you serialize access to that section of your code; in performance code you may want to try to avoid contention by using thread-specific data and when not possible using atomics. Last case is locking and when locking, minimize the time during which the lock is held (using messaging and double-checked locking though some claim it doesn't work -- works for me).
C 扩展
http://gcc.gnu.org/ml/libstdc++/2006-06/msg00089.html
Atomic+Builtins
http://sources.redhat.com/ml/libc-alpha/2005- 06/msg00132.html
http://www.redi.uklinux .net/doc/c++/shared_ptr.html
C Extensions
http://gcc.gnu.org/ml/libstdc++/2006-06/msg00089.html
Atomic+Builtins
http://sources.redhat.com/ml/libc-alpha/2005-06/msg00132.html
http://www.redi.uklinux.net/doc/c++/shared_ptr.html
不。GCC 内置程序对于编写操作系统、libc 甚至 pthreads 本身的人来说可能很有意义，但对于普通应用程序来说，没有理由不使用 pthreads 方法。
即使您始终使用 GCC，有一天您可能想要运行一个无法处理所有客户 GCC 扩展的静态分析工具。
No. The GCC built-ins probably make good sense to the guys who write operating systems, libc, and maybe pthreads itself, but for your average application there is no reason not to use the pthreads approach.
And even if you always use GCC, some day you may want to run a static analysis tool which won't handle all the customer GCC extensions.
如果您已经在使用 pthread，并且 pthread 锁定函数已经执行您想要的操作，那么最好使用 pthread 锁定函数。
这些原子内置函数只是高级原语的构建块； 编写这些更高级别的原语往往很棘手，任何错误都可能导致错误，这些错误可能需要很长时间才能显示出来（因为它们通常取决于时间）。 如果您已经拥有一个具有更高级别原语的库，该库可以执行您想要的操作并且速度足够快以满足您的需求（并且不要仅仅因为必须执行函数调用就假设它们太慢），那么最好不要重新发明车轮。
If you are already using pthread, and the pthread lock functions already do what you want, it is best to use the pthread lock functions.
These atomic builtins are just the building blocks for higher-level primitives; writing these higher-level primitives tends to be tricky, and any mistakes can cause errors which can take a long time to show up (since they usually depend on timing). If you already have a library with higher-level primitives which do what you want and are fast enough for your needs (and do not assume they are too slow just because you have to do a function call), it is best to not reinvent the wheel.
如果您打算使用 gcc 之外的其他东西来编译代码，则不会。 pthreads 是否给您带来了任何特定问题？
Not if you ever intend to compile the code with something other than gcc. Is pthreads causing you any specific problems?