3 ms·
__sync_fetch_and_add, __sync_add_and_fetch, __sync_val_compare_and_swap, and friends provide a full barrier so “no memory operand will be moved across the opera
by maw 16y ago
__sync_fetch_and_add, __sync_add_and_fetch, __sync_val_compare_and_swap, and friends provide a full barrier so “no memory operand will be moved across the operation, either forward or backward.” These operations are the basis for most (all?) lock-free algorithms.
What's lock-free about that? It sounds like locks to me, only you don't implement them yourself. What am I missing?
- philwelch 16y agoCompare-and-swap, for one, is a CPU instruction. There's no locking at any SW level with a CAS since you just call that instruction rather than locking, doing a compare, branching, doing a swap, and unlocking. Fetch-and-add seems to be a CPU instruction as well. You can implement these things with a lock, but it's not necessarily the case. Atomic instructions provide atomicity, but not locking per se. Locking is just another means to atomicity. A lock says "don't schedule another thread to access this resource until I say so", an atomic CPU instruction says "don't execute another CPU instruction in the middle of me". Locks are, as is often the case, both far more powerful and far more dangerous to use.