6 ms·

They are only system calls when you need to wait or wake up processes. https://en.m.wikipedia.org/wiki/Futex https://en.m.wikipedia.org/wiki/Futex

mehrdadn 9y ago
I was assuming contention but I guess I wasn't clear, sorry. I updated the post. But saying this "only" occurs when there is contention is very misleading since it makes it seem like the scenario of lock contention is a negligible concern. It's not.
- kllrnohj 9y ago
  Thread-suspending contended mutexes are already extremely slow. If you have a heavily-contended mutex you already have a major performance bug. If this is the kick in the pants you need to go fix it that's arguably a good thing ;) Note that mutex contention does not itself mean immediately falling back to futex - commonly you'll spinloop first and hope that resolves your contention (fast), then fall back to futex (slow)
  - mehrdadn 9y ago
    > If you have a heavily-contended mutex you already have a major performance bug. I can't really devote time to countering the unfounded assertion that every contended mutex must be a bug. It certainly isn't consistent with my experience, but if every problem you've solved could have been parallelized infinitely without increasing lock contention, more power to you.
    - asveikau 9y ago
      Let's put it this way. If every contended mutex were a bug, why not remove the mutex and let the code run as-is? No, you wouldn't, so no, not a bug.
      - mehrdadn 9y ago
        > Let's put it this way. If every contended mutex were a bug, why not remove the mutex and let the code run as-is? No, you wouldn't, so no, not a bug. I mean, the parent's argument is wrong, but isn't that naive. Presumably the argument is a bad (yet still correct) solution would result in lock contention while a better solution would e.g. use a different algorithm that is more parallelizable.
    - kllrnohj 9y ago
      > I can't really devote time to countering the unfounded assertion that every contended mutex must be a bug. Good, because that's not what I said. If you're heavily hitting futex convention you do have a performance bug, though. You might be confused with general contention that's being resolved with a spinlock rather than futex wait, though.
      - mehrdadn 9y ago
        >> I can't really devote time to countering the unfounded assertion that every contended mutex must be a bug. > Good, because that's not what I said. It is literally what you said: >>> If you have a heavily-contended mutex you already have a major performance bug. If this is the kick in the pants you need to go fix it that's arguably a good thing ;) > You might be confused with general contention that's being resolved with a spinlock rather than futex wait, though. I'm not confusing them at all; I'm literally reading exactly what you wrote. You literally said contended mutexes are necessarily bugs (right here^) and that you considered mutexes to include the initial spinlocks ("note that mutex contention does not itself mean immediately falling back to futex - commonly you'll spinloop first"). But maybe you meant to say something else?
        kllrnohj 9y ago
        I literally said spin loop resolving is fast. Maybe read more than the single phrase you're pulling out of context to go on a rant about?
        netheril96 9y ago
        He said "heavily contended", and then you dropped the "heavily" prefix and claimed that was literally what he said. That adverb is material to the discussion and your dropping it completely changes the meaning. I concur with his opinion. Infrequent contention is not a bug; otherwise no mutex is needed. Frequent contention (or heavy contention in his words) is a performance bug.
        mehrdadn 9y ago
        > He said "heavily contended", and then you dropped the "heavily" prefix and claimed that was literally what he said. That adverb is material to the discussion and your dropping it completely changes the meaning. "Heavily" was not dropped intentionally at all. Add it back to my comments. It changes nothing whatsoever. The incredible opinion that every problem can be necessarily parallelized without eventually resulting in contention (and I license you to freely modify this term with 'light', 'heavy', 'medium-rare', 'salted', 'peppered', or 'grilled at 450F' to your taste) is so fantastically absurd that I cannot believe you are debating it. I definitely don't know how you can justify such an unfounded claim with no evidence and I certainly have no interest in wasting time debating it. As I said earlier: if you never encounter problems that exhibit eventual scalability limits, more power to you.

mehrdadn 9y ago

I was assuming contention but I guess I wasn't clear, sorry. I updated the post. But saying this "only" occurs when there is contention is very misleading since it makes it seem like the scenario of lock contention is a negligible concern. It's not.

kllrnohj 9y ago
Thread-suspending contended mutexes are already extremely slow. If you have a heavily-contended mutex you already have a major performance bug. If this is the kick in the pants you need to go fix it that's arguably a good thing ;) Note that mutex contention does not itself mean immediately falling back to futex - commonly you'll spinloop first and hope that resolves your contention (fast), then fall back to futex (slow)
- mehrdadn 9y ago
  > If you have a heavily-contended mutex you already have a major performance bug. I can't really devote time to countering the unfounded assertion that every contended mutex must be a bug. It certainly isn't consistent with my experience, but if every problem you've solved could have been parallelized infinitely without increasing lock contention, more power to you.
  - asveikau 9y ago
    Let's put it this way. If every contended mutex were a bug, why not remove the mutex and let the code run as-is? No, you wouldn't, so no, not a bug.
    - mehrdadn 9y ago
      > Let's put it this way. If every contended mutex were a bug, why not remove the mutex and let the code run as-is? No, you wouldn't, so no, not a bug. I mean, the parent's argument is wrong, but isn't that naive. Presumably the argument is a bad (yet still correct) solution would result in lock contention while a better solution would e.g. use a different algorithm that is more parallelizable.
  - kllrnohj 9y ago
    > I can't really devote time to countering the unfounded assertion that every contended mutex must be a bug. Good, because that's not what I said. If you're heavily hitting futex convention you do have a performance bug, though. You might be confused with general contention that's being resolved with a spinlock rather than futex wait, though.
    - mehrdadn 9y ago
      >> I can't really devote time to countering the unfounded assertion that every contended mutex must be a bug. > Good, because that's not what I said. It is literally what you said: >>> If you have a heavily-contended mutex you already have a major performance bug. If this is the kick in the pants you need to go fix it that's arguably a good thing ;) > You might be confused with general contention that's being resolved with a spinlock rather than futex wait, though. I'm not confusing them at all; I'm literally reading exactly what you wrote. You literally said contended mutexes are necessarily bugs (right here^) and that you considered mutexes to include the initial spinlocks ("note that mutex contention does not itself mean immediately falling back to futex - commonly you'll spinloop first"). But maybe you meant to say something else?
      - kllrnohj 9y ago
        I literally said spin loop resolving is fast. Maybe read more than the single phrase you're pulling out of context to go on a rant about?
      - netheril96 9y ago
        He said "heavily contended", and then you dropped the "heavily" prefix and claimed that was literally what he said. That adverb is material to the discussion and your dropping it completely changes the meaning. I concur with his opinion. Infrequent contention is not a bug; otherwise no mutex is needed. Frequent contention (or heavy contention in his words) is a performance bug.
        mehrdadn 9y ago
        > He said "heavily contended", and then you dropped the "heavily" prefix and claimed that was literally what he said. That adverb is material to the discussion and your dropping it completely changes the meaning. "Heavily" was not dropped intentionally at all. Add it back to my comments. It changes nothing whatsoever. The incredible opinion that every problem can be necessarily parallelized without eventually resulting in contention (and I license you to freely modify this term with 'light', 'heavy', 'medium-rare', 'salted', 'peppered', or 'grilled at 450F' to your taste) is so fantastically absurd that I cannot believe you are debating it. I definitely don't know how you can justify such an unfounded claim with no evidence and I certainly have no interest in wasting time debating it. As I said earlier: if you never encounter problems that exhibit eventual scalability limits, more power to you.