GCC Atomic Builtins instead of pthread?

Question

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.

Answer 1

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

Answer 2

Is this a good idea?

Not if you ever intend to compile the code with something other than gcc. Is pthreads causing you any specific problems?

Answer 3

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.

Answer 4

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.

Answer 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).