Live data from Hacker News

Locking in WebKit

webkit.org

21–30 of 42 posts

Re: Locking in WebKit

#21

Earlier quoted context omitted.

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

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-...

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!

Re: Locking in WebKit

#22

Earlier quoted context omitted.

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-...

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 mea…

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.

Re: Locking in WebKit

#23

Earlier quoted context omitted.

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

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-...

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.

Re: Locking in WebKit

#24
WTF seems to be a very useful library, especially since the C++ standard library is so criminally small. I hope the WebKit guy can release it as a standalone library that will benefit many C++ developers. (Currently I can copy WTF into my own project, but I don't know how to use it due to lack of documentation).

Re: Locking in WebKit

#25
WebKit has its own lock and malloc implementations and many other redoes of standard library. Given that Apple's engineers have a great deal of influence on all of WebKit, libc++ and their operating systems, I wonder why they do not port those WebKit implementations onto OS X and iOS.

Re: Locking in WebKit

#26

WTF seems to be a very useful library, especially since the C++ standard library is so criminally small. I hope the WebKit guy can release it as a standalone library that will benefit many C++ developers. (Currently I can copy WTF into my own project, but I don't know how to use it due to lack of documentation).

> I hope the WebKit guy can release it as a standalone library that will benefit many C++ developers.

+1. Even just the WTF::Lock, WTF::Condition and supporting code would be useful.

Re: Locking in WebKit

#28
It would be interesting to have more CPU support for critical sections. You could have an option to prevent interrupts on a fence instruction during short critical sections. Interrupts would be prevented for a maximum number of instructions set by an operating system controlled register, so user threads couldn't lock up a CPU. Running out the instruction count would cause an exception interrupt. The limit on number of instructions would be small; maybe 10 or 20.

Side issue: what about page faults in critical sections? Should critical sections be allowed to cross page boundaries?

Post reply on HN