GCC原子内置而不是pthread？

我发现了以下文章：

它指的是

本文建议使用GCC原子内置工具，而不是pthread同步工具

这是个好主意吗？

另外，mysql的帖子显然是误导性的。原子内置无法替换所有pthread工具。例如，锁定要求，如果无法获取锁，线程必须等待。换句话说，它要求操作系统等待，因此等待是被动的。简单的GCC内置无法做到这一点。

这是个好主意吗

---

如果您打算用gcc以外的东西编译代码，就不会这样做。pthreads会给您带来任何具体问题吗？

不会。GCC内置对编写操作系统、libc以及pthreads本身的人来说可能很有意义，但对于您的普通应用程序来说，没有理由不使用pthreads方法

---

即使您总是使用GCC，总有一天您可能会想要运行一个静态分析工具，它不会处理所有客户GCC扩展。

如果您已经在使用pthread，并且pthread lock函数已经完成了您想要的功能，那么最好使用pthread lock函数

---

这些原子内置物只是高级原语的构建块；编写这些更高级别的原语往往很棘手，任何错误都可能导致需要很长时间才能出现的错误（因为它们通常取决于时间）。如果您已经有了一个包含高级原语的库，这些原语可以执行您想要的操作，并且速度足够快，可以满足您的需要（不要因为必须执行函数调用而认为它们太慢），最好不要重新发明轮子。

如果您想提高性能，原子内置是有意义的。内置允许您最小化互斥体序列化引起的争用。当您使用互斥体并创建关键会话时，您序列化了对代码该部分的访问；在性能代码中，您可能希望通过使用特定于线程的数据以及在不可能的情况下使用原子来避免争用。最后一种情况是锁定，当锁定时，尽量减少持有锁定的时间（使用消息传递和双重检查锁定，尽管有人声称它不起作用——对我有效）

pthreads没有问题，只是想知道切换到那些GCC内置是否值得。我将始终使用GCC进行编译，没有机会改变这一点。“如果它没有损坏，就不要修复它”是我的座右铭；我希望他们也能在其他编译器上工作，包括非英特尔处理器的编译器？