Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Locking in WebKit

webkit.org

Post reply on HN
Print view View original

11–20 of 42 posts

Re: Locking in WebKit

#11

Post by pizlonator »

eridius wrote: post #5

Two things come to mind when reading this: 1. WTF::Lock is using sequential consistency for all of the slow path operations. Surely this isn't necessary and it could still use acquire/release for most of them (like it does in the fast path). 2. Ditching OS-provided mutexes has one possibly-important drawback on OS X and iOS: lack of priority donation. Recent versions of OS X and iOS have a Quality Of Service implemen…

Weakening the consistency of operations on the slow path is not going to be a speed-up. Those paths are not dominated by pipeline effects inside the CPU. They are dominated by context switches and memory contention. So, SC is exactly right: it's harder to get wrong and exactly the same speed.

It's true that WTF::Lock doesn't support priority inheritance. That's fine for WebKit's threads.

Re: Locking in WebKit

#12

Post by pizlonator »

exDM69 wrote: post #3

One byte per mutex sounds a bit suspicious given that atomic operations typically work on a word or cache line granularity. If you have two mutexes in the same cache line, false sharing occurs and the CPU interconnect gets busy. Locking two uncontended mutexes in same cache line on different cores ends up executing serially because the cores need to snoop each other's caches. Some benchmarks might be useful to see ho…

The points isn't to have two mutexes in the same cache line. The point is to have a mutex plus the data that the mutex protects in the same cache line.

Re: Locking in WebKit

#13

Post by pizlonator »

cokernel_hacker wrote: post #4

Spinning in locks are always tricky business. The sharpest thorn, to me, is: what happens when you are running inside the critical section and your thread gets preempted? Well, now the next thread which tries to acquire the lock is stuck waiting. But waiting for what? Waiting for the original thread to get scheduled. Now, the OS has no idea that the original thread should get scheduled again and is free to continue s…

The post details why we spin for the amount of time that we do. It turns out that there is a wealth of measurements that support our 40-spins-while-yielding rule. It worked for a strangely diverse set of workloads:

- IBM Research found it to be optimal on the portBOB benchmark on a 12-way AIX POWER box in 1999. - I found it to be optimal for DaCapo multi-threaded benchmarks on both AMD and Intel SMPs in ~2007. - I again found it to be optimal for WebKit these days.

The point of spinning for a short time and then parking is that parking is hella slow. That's why you can get away with spinning. Spinning is net profitable so long as the amount you spin for is much smaller than the amount of time the OS will waste while parking.

Re: Locking in WebKit

#14

Post by awinter-py »

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

Re: Locking in WebKit

#15

Post by pizlonator »

awinter-py wrote: post #14

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

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

Re: Locking in WebKit

#16

Post by occasionalreedr »

Please replace the very slow Mac OS X pthread_mutex locks with the WTF::Lock implementation to benefit all applications. I can live with it still being 64 bytes and the scheduling being not completely fair. The OS X pthread mutexes are several times slower than Linux on the same hardware.

Re: Locking in WebKit

#19

Post by amelius »

emehrkay wrote: post #2

Random observation: WTF would be a great base exception in a new, hip programming language. WTF.happened WTF.context ...and so on

Not a good idea, because now you cannot easily grep anymore for "WTF" in source code comments :)

Re: Locking in WebKit

#20

Post by awinter-py »

pizlonator wrote: post #15
awinter-py wrote: post #14

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

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

Post reply on HN