4 ms·

My blog post was quite clear that I'm talking about futexes, and then when it fails to get a lock that it goes into the kernel. Seriously, that's how everyone d

My blog post was quite clear that I'm talking about futexes, and then when it fails to get a lock that it goes into the kernel. Seriously, that's how everyone did it from Solaris to Windows before Linux "invented" the concept AND it's been in Linux for a decade. When somebody says "mutex", you have to assume they already mean "futex".

javert 14y ago
If you fail to get the lock, then you have to wait on the lock, so you might as well go into the kernel anyway. That's the reason futexes do that, instead of just letting the thread spin. True, there are scenarios when you might prefer to spin, but they're pretty specialized. My blog post was quite clear that I'm talking about futexes No, you never mention the word "futex." When somebody says "mutex", you have to assume they already mean "futex". I don't think that's a valid generalization at all.
- jamesaguilar 14y ago
  > I don't think that's a valid generalization at all. Especially given he was complaining about syscall costs . . . which are nonexistent with futexes . . .
  - robertgraham 14y ago
    They are NOT non-existent, they happen a lot in contention. That's why code fails to scale: as you add CPUs, contentions happen a lot more often, and the number of syscalls shoot through the roof.
    - jamesaguilar 14y ago
      But the cost is not the syscalls . . . it's all those threads getting stopped, swapping memory in and out of the cache, etc. The syscall cost is minor by comparison. At any rate, you've definitely overstated the case against mutexes in this post. At most, the advice should have been "avoid designs that will suffer from a lot of contention" like locking with lots of shared mutable state. It really has nothing to do with threads-vs-processes as you've made it out to do.
- robertgraham 14y ago
  The entire point of the post was talk about "lock-free" algorithms where two cores can make forward progress without either having to wait or spin. What systems have mutexes that aren't built like futexes?
  - javert 14y ago
    Kernels, and probably any kind of parallel user-level runtime like Erlang.

javert 14y ago

If you fail to get the lock, then you have to wait on the lock, so you might as well go into the kernel anyway. That's the reason futexes do that, instead of just letting the thread spin. True, there are scenarios when you might prefer to spin, but they're pretty specialized. My blog post was quite clear that I'm talking about futexes No, you never mention the word "futex." When somebody says "mutex", you have to assume they already mean "futex". I don't think that's a valid generalization at all.

jamesaguilar 14y ago
> I don't think that's a valid generalization at all. Especially given he was complaining about syscall costs . . . which are nonexistent with futexes . . .
- robertgraham 14y ago
  They are NOT non-existent, they happen a lot in contention. That's why code fails to scale: as you add CPUs, contentions happen a lot more often, and the number of syscalls shoot through the roof.
  - jamesaguilar 14y ago
    But the cost is not the syscalls . . . it's all those threads getting stopped, swapping memory in and out of the cache, etc. The syscall cost is minor by comparison. At any rate, you've definitely overstated the case against mutexes in this post. At most, the advice should have been "avoid designs that will suffer from a lot of contention" like locking with lots of shared mutable state. It really has nothing to do with threads-vs-processes as you've made it out to do.
robertgraham 14y ago
The entire point of the post was talk about "lock-free" algorithms where two cores can make forward progress without either having to wait or spin. What systems have mutexes that aren't built like futexes?
- javert 14y ago
  Kernels, and probably any kind of parallel user-level runtime like Erlang.