3 ms·

Things UNIX can do atomically

36 points by bgray 16y ago

billswift 16y ago
This was just posted 4 months ago http://news.ycombinator.com/item?id=1340115 http://news.ycombinator.com/item?id=1340115
- sundarurfriend 16y ago
  It is amusing to see that you commented in the linked submission too, saying the same thing (that it was posted 4 months before that): > This was post here about 4 months ago, http://news.ycombinator.com/item?id=1035100 http://news.ycombinator.com/item?id=1035100 , lots of good comments. Thanks for keeping track, found it useful.
- _delirium 16y ago
  Hmm, identical URL too. I thought HN had duplicate-URL checking? Or it's only for duplicate URLs within some recent timeframe?
  - wmf 16y ago
    Yeah, there's a time limit (or something similar).
    - bmelton 16y ago
      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 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 ago
  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.

36 points by bgray 16y ago

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

sundarurfriend 16y ago
It is amusing to see that you commented in the linked submission too, saying the same thing (that it was posted 4 months before that): > This was post here about 4 months ago, http://news.ycombinator.com/item?id=1035100 http://news.ycombinator.com/item?id=1035100 , lots of good comments. Thanks for keeping track, found it useful.
_delirium 16y ago
Hmm, identical URL too. I thought HN had duplicate-URL checking? Or it's only for duplicate URLs within some recent timeframe?
- wmf 16y ago
  Yeah, there's a time limit (or something similar).
  - bmelton 16y ago
    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 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 ago
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.