4 ms·

> rarely an excuse for not having one, or even multiple, fine-grained locks in any object that has things that need to be synchronized 'wtf' is right. locking

> rarely an excuse for not having one, or even multiple, fine-grained locks in any object that has things that need to be synchronized 'wtf' is right. locking sometimes adds as much risk as it removes.

pizlonator 11y ago
I often hear this kind of claim. Do you have evidence? Because I just presented evidence that locks are awesome.
- awinter-py 11y ago
  race conditions > Textbooks will tell you that if you always lock in the same order, you will never get this kind of deadlock. Practice will tell you that this approach doesn't scale: when I create a new lock, I don't understand enough of the kernel to figure out where in the 5000 lock hierarchy it will fit. https://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/x441.html https://www.kernel.org/pub/linux/kernel/people/rusty/kernel-...
  - pizlonator 11y ago
    It's true that when you write code, that code can have bugs. When I write file system code and I have a bug, we call it "data loss". When I write user interface code and I have a bug, we call it "not user friendly". And when I write code that uses locks and it has a bug we call it a "race condition". Just because you can give it a name doesn't mean it's bad. Just because a programming idiom can be misused doesn't mean it's bad. All programming idioms can be misused! WebKit's lock hierarchies don't involve 5000 locks. We try to do as little work as possible while holding a lock, and that usually means that we don't hold more than one lock at a time. It's true that when you hold multiple locks at a time, it can get confusing. So, don't do that!
    - awinter-py 11y ago
      If you're just saying 'when locking is cheap, fine-grained locks can be easier to deal with vs coarse locks' I can agree with that.
  - anarazel 11y ago
    Only that lock-free (or wait free, or even obstruction-free) datastructures aren't exactly trivial to implement correctly either. Besides often having architectural impact (Uh, Oh, I now need to declare quiescent periods?), they're extremely hard to debug, and there's even less automated verification than for locking.
    - awinter-py 11y ago
      there are many design alternatives to locking. Lock-free synchronization is one of them, but queueing is another. The best alternative is to simplify your control flow so that you don't need as much synchronization.
      - scott_s 11y ago
        I have never seen lock-free synchronization touted as a simpler alternative to locking. (And I do lock-free synchronization.) Avoiding synchronization as much as possible is a good principle - one which I use often, and I actually contend is the only way to write scalable code. But someone always need to eventually synchronize. Even if it's not your code explicitly, somewhere, your code will have to rely on code someone else wrote that synchronizes. This article is aimed to those people.

pizlonator 11y ago

I often hear this kind of claim. Do you have evidence? Because I just presented evidence that locks are awesome.

awinter-py 11y ago
race conditions > Textbooks will tell you that if you always lock in the same order, you will never get this kind of deadlock. Practice will tell you that this approach doesn't scale: when I create a new lock, I don't understand enough of the kernel to figure out where in the 5000 lock hierarchy it will fit. https://www.kernel.org/pub/linux/kernel/people/rusty/kernel-locking/x441.html https://www.kernel.org/pub/linux/kernel/people/rusty/kernel-...
- pizlonator 11y ago
  It's true that when you write code, that code can have bugs. When I write file system code and I have a bug, we call it "data loss". When I write user interface code and I have a bug, we call it "not user friendly". And when I write code that uses locks and it has a bug we call it a "race condition". Just because you can give it a name doesn't mean it's bad. Just because a programming idiom can be misused doesn't mean it's bad. All programming idioms can be misused! WebKit's lock hierarchies don't involve 5000 locks. We try to do as little work as possible while holding a lock, and that usually means that we don't hold more than one lock at a time. It's true that when you hold multiple locks at a time, it can get confusing. So, don't do that!
  - awinter-py 11y ago
    If you're just saying 'when locking is cheap, fine-grained locks can be easier to deal with vs coarse locks' I can agree with that.
- anarazel 11y ago
  Only that lock-free (or wait free, or even obstruction-free) datastructures aren't exactly trivial to implement correctly either. Besides often having architectural impact (Uh, Oh, I now need to declare quiescent periods?), they're extremely hard to debug, and there's even less automated verification than for locking.
  - awinter-py 11y ago
    there are many design alternatives to locking. Lock-free synchronization is one of them, but queueing is another. The best alternative is to simplify your control flow so that you don't need as much synchronization.
    - scott_s 11y ago
      I have never seen lock-free synchronization touted as a simpler alternative to locking. (And I do lock-free synchronization.) Avoiding synchronization as much as possible is a good principle - one which I use often, and I actually contend is the only way to write scalable code. But someone always need to eventually synchronize. Even if it's not your code explicitly, somewhere, your code will have to rely on code someone else wrote that synchronizes. This article is aimed to those people.