

Things UNIX can do atomically - bgray
http://rcrowley.org/2010/01/06/things-unix-can-do-atomically.html

======
billswift
This was just posted 4 months ago
<http://news.ycombinator.com/item?id=1340115>

~~~
_delirium
Hmm, identical URL too. I thought HN had duplicate-URL checking? Or it's only
for duplicate URLs within some recent timeframe?

~~~
wmf
Yeah, there's a time limit (or something similar).

~~~
bmelton
Given the posts above this, I can't help but wonder how close that time
threshold is to four months.

It makes sense though, I mean, if I link to the mozilla.org home page due to a
new software release, that shouldn't preclude the next guy from being able to
link there when they make their _next_ release, right?

------
maw
___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
Compare-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.

