4 ms·

We use something quite similar to this. It won’t save you from accidental recursive locking though, but I’m not sure any solution will.

pavlov 4y ago
If the problem is really just recursive lock calls on the same thread, then PTHREAD_MUTEX_RECURSIVE should do the trick?
- saagarjha 4y ago
  Generally PTHREAD_MUTEX_RECURSIVE is a band-aid, not a solution.
  - AnimalMuppet 4y ago
    Could you explain? A simple drive-by condemnation doesn't tell us why, or give us any reason to agree with you.
    - gpderetta 4y ago
      This gets shared periodically here: https://groups.google.com/g/comp.programming.threads/c/tcrTKnfP8HI/m/me2K7_byNdgJ https://groups.google.com/g/comp.programming.threads/c/tcrTK...
    - secondcoming 4y ago
      If you find yourself needing recursive locks your design is wrong. They were invented as a dare.
    - loeg 4y ago
      They mean you don't know and can't reason about lock state. To design concurrent systems with good performance and correctness, you need to be able to reason about lock state statically. Here's some random article I found in 30 seconds of googling that seems to go into more depth on the subject: https://blog.stephencleary.com/2013/04/recursive-re-entrant-locks.html https://blog.stephencleary.com/2013/04/recursive-re-entrant-...
      - AnimalMuppet 4y ago
        But you can reason about lock state statically with recursive locks. I have a function A, that accesses and modifies a data structure X. I have another function, B, that modifies X, but that also calls A to do part of its work. And I have a function C that calls A, but never accesses X except through A. I can perfectly well statically reason about a recursive mutex that both A and B take to protect access to X. It's not magic.
        saagarjha 4y ago
        I mean it exists for a reason, there are some rare cases where it might be the right tradeoff to use it. However, these cases are pretty rare: what’s far more likely is that the critical region is not considered well and the recursive mutex is a patch for “I don’t really know what’s going on here, let’s just use the thing that works”. You can form your own opinion on this but I actually find it common for people to avoid designs like yours specifically to avoid the recursive lock; usually the alternative is about as ergonomic and it reduces the need to reason about recursive locking.

pavlov 4y ago

If the problem is really just recursive lock calls on the same thread, then PTHREAD_MUTEX_RECURSIVE should do the trick?

saagarjha 4y ago
Generally PTHREAD_MUTEX_RECURSIVE is a band-aid, not a solution.
- AnimalMuppet 4y ago
  Could you explain? A simple drive-by condemnation doesn't tell us why, or give us any reason to agree with you.
  - gpderetta 4y ago
    This gets shared periodically here: https://groups.google.com/g/comp.programming.threads/c/tcrTKnfP8HI/m/me2K7_byNdgJ https://groups.google.com/g/comp.programming.threads/c/tcrTK...
  - secondcoming 4y ago
    If you find yourself needing recursive locks your design is wrong. They were invented as a dare.
  - loeg 4y ago
    They mean you don't know and can't reason about lock state. To design concurrent systems with good performance and correctness, you need to be able to reason about lock state statically. Here's some random article I found in 30 seconds of googling that seems to go into more depth on the subject: https://blog.stephencleary.com/2013/04/recursive-re-entrant-locks.html https://blog.stephencleary.com/2013/04/recursive-re-entrant-...
    - AnimalMuppet 4y ago
      But you can reason about lock state statically with recursive locks. I have a function A, that accesses and modifies a data structure X. I have another function, B, that modifies X, but that also calls A to do part of its work. And I have a function C that calls A, but never accesses X except through A. I can perfectly well statically reason about a recursive mutex that both A and B take to protect access to X. It's not magic.
      - saagarjha 4y ago
        I mean it exists for a reason, there are some rare cases where it might be the right tradeoff to use it. However, these cases are pretty rare: what’s far more likely is that the critical region is not considered well and the recursive mutex is a patch for “I don’t really know what’s going on here, let’s just use the thing that works”. You can form your own opinion on this but I actually find it common for people to avoid designs like yours specifically to avoid the recursive lock; usually the alternative is about as ergonomic and it reduces the need to reason about recursive locking.