Spinning around: Please don’t – Common problems with spin locks • Hacker News Board

Re: Spinning around: Please don’t – Common problems with spin locks

#61

Post by pjmlp » Thu, Jan 29, 2026, 2:56 PM UTC

bluGill wrote: post #60

pjmlp wrote: post #50

Earlier quoted context omitted.

I never get the single threaded assertions regarding CPU performance, it is mostly useless in the day of premptive scheduling in modern OSes. Yes it matters on MS-DOS like OS design, like some embedded deployments and that is about it. It is even impossible to guarantee a process doesn't get rescheduled into another CPU with the performance impact it entails, unless the process explicitly sets its CPU affinity.

If you don't allow complev things like spinlocks then all that is left is single thread performance.

Except that ignores the amount of times the OS preempts the thread, or moves it into another CPU trashing all the cache contents in the process, and related NUMA patterns.

The way it is measured, is mostly ideal, assuming that threads run to completion without any of those side effects taking place.

Re: Spinning around: Please don’t – Common problems with spin locks

#62

Post by pizlonator » Thu, Jan 29, 2026, 2:57 PM UTC

Lectem wrote: post #37

pizlonator wrote: post #27

TFA lists WebKit as a project that "does it wrong". The author should read https://webkit.org/blog/6161/locking-in-webkit/ so that they understand what they are talking about. WebKit does it right in the sense that: - It as an optimal amount of spinning - Threads wait (instead of spinning) if the lock is not available immediately-ish And we know that the algorithms are optimal based on rigorous experiments.

The author (me) actually read this long ago > - It as an optimal amount of spinning No it isn't, it has a fixed number of yields, which has a very different duration on various CPUs > Threads wait (instead of spinning) if the lock is not available immediately-ish They use parking lots, which is one way to do futew (in fact, WaitOnAddress is implemented similarly). And no if you read the code, they do spin. Worse, the…

> No it isn't, it has a fixed number of yields, which has a very different duration on various CPUs

You say this with zero data.

I know that yielding 40 times is optimal for WebKit because I measured it. In fact it was re-measured many times because folks like you would doubt that it could’ve optimal, suggest something different, and then again the 40 yields would be shown to be optimal.

> And no if you read the code, they do spin. Worse, they actually yield the thread before properly parking.

Threads wait if the lock is not available immediately-ish.

Yes, they spin by yielding. Spinning by pausing or doing anything else results in worse performance. We measured this countless times.

I think the mistake you’re making is that you’re imagining how locks work. Whereas what I am doing is running rigorous experiments that involved putting WebKit through larger scale tests

Re: Spinning around: Please don’t – Common problems with spin locks

#63

Post by rdtsc » Fri, Jan 30, 2026, 4:26 AM UTC

Lectem wrote: post #41

rdtsc wrote: post #25

> Notice that in the Skylake Client microarchitecture the RDTSC instruction counts at the machine’s guaranteed P1 frequency independently of the current processor clock (see the INVARIANT TSC property), and therefore, when running in Intel® Turbo-Boost-enabled mode, the delay will remain constant, but the number of instructions that could have been executed will change. rdtsc may execute out of order, so sometimes an…

The issue with that is that a load fence may be very detrimental to perf. It doesn't really matter if rdtsc executes out of order in this code anyway, and there is no need for sync between cores.

You could first measure the perf impact of the fence instruction and then subtract that out? But yeah I guess it may not matter much for quick and dirty calibration loop.

I found somewhere (https://aloiskraus.wordpress.com/2018/06/16/why-skylakex-cpu...) that the pause instruction had this wild cycle difference between different CPU and it caused some grief, I had no idea. I stopped doing low level coding a while back.

Re: Spinning around: Please don’t – Common problems with spin locks

#64

Post by Lectem » Sat, Jan 31, 2026, 12:55 PM UTC

pizlonator wrote: post #62

Lectem wrote: post #37

Earlier quoted context omitted.

The author (me) actually read this long ago > - It as an optimal amount of spinning No it isn't, it has a fixed number of yields, which has a very different duration on various CPUs > Threads wait (instead of spinning) if the lock is not available immediately-ish They use parking lots, which is one way to do futew (in fact, WaitOnAddress is implemented similarly). And no if you read the code, they do spin. Worse, the…

> No it isn't, it has a fixed number of yields, which has a very different duration on various CPUs You say this with zero data. I know that yielding 40 times is optimal for WebKit because I measured it. In fact it was re-measured many times because folks like you would doubt that it could’ve optimal, suggest something different, and then again the 40 yields would be shown to be optimal. > And no if you read the code…

>You say this with zero data.

Or so you assume

> Spinning by pausing or doing anything else results in worse performance. We measured this countless times.

And I've seen the issue in hundreds of captures using a profiler. I suppose we just have a different definitions of the what "worse performance" is.

> Whereas what I am doing is running rigorous experiments that involved putting WebKit through larger scale tests

Or perhaps the fish was drown in the stats, or again different metrics.

Re: Spinning around: Please don’t – Common problems with spin locks

#65

Post by pizlonator » Sat, Jan 31, 2026, 8:53 PM UTC

Lectem wrote: post #64

pizlonator wrote: post #62

Earlier quoted context omitted.

> No it isn't, it has a fixed number of yields, which has a very different duration on various CPUs You say this with zero data. I know that yielding 40 times is optimal for WebKit because I measured it. In fact it was re-measured many times because folks like you would doubt that it could’ve optimal, suggest something different, and then again the 40 yields would be shown to be optimal. > And no if you read the code…

>You say this with zero data. Or so you assume > Spinning by pausing or doing anything else results in worse performance. We measured this countless times. And I've seen the issue in hundreds of captures using a profiler. I suppose we just have a different definitions of the what "worse performance" is. > Whereas what I am doing is running rigorous experiments that involved putting WebKit through larger scale tests O…

> Or so you assume

You're not including data in your discussion of this topic. Your post included zero data.

My post on WTF locks has tons of data.

So, I'm not assuming; I'm observing.

> And I've seen the issue in hundreds of captures using a profiler. I suppose we just have a different definitions of the what "worse performance" is.

Nobody cares what you saw in the profiler.

What matters is the performance users experience.

By any metric of observable performance, yielding is the optimal way of spinning.

Re: Spinning around: Please don’t – Common problems with spin locks

#66

Post by ablob » Fri, Feb 06, 2026, 8:12 PM UTC

pizlonator wrote: post #62

Lectem wrote: post #37

Earlier quoted context omitted.

The author (me) actually read this long ago > - It as an optimal amount of spinning No it isn't, it has a fixed number of yields, which has a very different duration on various CPUs > Threads wait (instead of spinning) if the lock is not available immediately-ish They use parking lots, which is one way to do futew (in fact, WaitOnAddress is implemented similarly). And no if you read the code, they do spin. Worse, the…

> No it isn't, it has a fixed number of yields, which has a very different duration on various CPUs You say this with zero data. I know that yielding 40 times is optimal for WebKit because I measured it. In fact it was re-measured many times because folks like you would doubt that it could’ve optimal, suggest something different, and then again the 40 yields would be shown to be optimal. > And no if you read the code…

>> No it isn't, it has a fixed number of yields, which has a very different duration on various CPUs

> You say this with zero data.

Wouldn't the null hypothesis be that the same program behaves differently on different CPUs? Is "different people require different amounts of time to run 100m" a statement that requires data?