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

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

siliceum.com

Post reply on HN
Print view View original

11–20 of 66 posts

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

#11

Post by fasterik »

jcranmer wrote: post #5

The basic rule of writing your own cross-thread datastructures like mutexes or condition variables is... don't, unless you have very good reason not to. If you're in that rare circumstance where you know the library you're using isn't viable for some reason, then the next best rule is to use your OS's version of a futex as the atomic primitive, since it's going to solve most of the pitfalls for you automatically. The…

As always: use standard libraries first, profile, then write your own if the data indicate that it's necessary. To your point, the standard library probably already uses the OS primitives under the hood, which themselves do a short userspace spin-wait and then fall back to a kernel wait queue on contention. If low latency is a priority, the latter might be unacceptable.

The following is an interesting talk where the author used a custom spinlock to significantly speed up a real-time physics solver.

Dennis Gustafsson – Parallelizing the physics solver – BSC 2025 https://www.youtube.com/watch?v=Kvsvd67XUKw

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

#12

Post by yjftsjthsd-h »

bluGill wrote: post #9
yjftsjthsd-h wrote: post #7

Earlier quoted context omitted.

I don't think that's fair. You can go fast, just not more than one task at a time.

Modern CPUs (since around 2000) go faster in large part because they have multiple cores that can do more than one thing in a time. If your program needs to go faster using more cores is often your best answer and then you will need these tricks. (SIMD or the GPU are also common answers that might or might not be better for your problem)

Modern CPUs can do 4-5 GHz singled threaded. (Sometimes you can even get a higher clock speed by disabling other cores.) This somewhat outpaces "a 1mhz 6502" even without parallelization.

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

#13

Post by bluGill »

yjftsjthsd-h wrote: post #12
bluGill wrote: post #9

Earlier quoted context omitted.

Modern CPUs (since around 2000) go faster in large part because they have multiple cores that can do more than one thing in a time. If your program needs to go faster using more cores is often your best answer and then you will need these tricks. (SIMD or the GPU are also common answers that might or might not be better for your problem)

Modern CPUs can do 4-5 GHz singled threaded. (Sometimes you can even get a higher clock speed by disabling other cores.) This somewhat outpaces "a 1mhz 6502" even without parallelization.

They can, but nobody runs a single process on such CPUs. They run some form of OS which implements spinlock, mutexes, and all these other complex things.

I suppose someplace someone is running an embedded system without an OS on such a processor - but I'd expect they are still using extra cores and so have all of the above tricks someplace.

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

#14

Post by [deleted] »

jcranmer wrote: post #5

The basic rule of writing your own cross-thread datastructures like mutexes or condition variables is... don't, unless you have very good reason not to. If you're in that rare circumstance where you know the library you're using isn't viable for some reason, then the next best rule is to use your OS's version of a futex as the atomic primitive, since it's going to solve most of the pitfalls for you automatically. The…

[deleted]

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

#15

Post by wizzwizz4 »

kccqzy wrote: post #8
jcranmer wrote: post #5

The basic rule of writing your own cross-thread datastructures like mutexes or condition variables is... don't, unless you have very good reason not to. If you're in that rare circumstance where you know the library you're using isn't viable for some reason, then the next best rule is to use your OS's version of a futex as the atomic primitive, since it's going to solve most of the pitfalls for you automatically. The…

Another time when writing a quick and dirty spinlock is reasonable is inside a logging library. A logging library would normally use a full-featured mutex, but what if we want the mutex implementation to be able to log? Say the mutex can log that it is non recursive yet the same thread is acquiring it twice; or that it has detected a deadlock. The solution is to introduce a special subset of the logging library to us…

I'm not sure how a spinlock solves this problem. Wouldn't that just cause the process to hang busy?

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

#16

Post by maxbond »

kelnos wrote: post #10
nh23423fefe wrote: post #4

Earlier quoted context omitted.

Isn't it the opposite? The complication is evidence of function. The simple code doesn't work.

That assertion feels suspiciously like a logical fallacy.

Not really. If the solution has less complexity than is inherent in the problem, it can't possibly work. If the solution has complexity equal to or greater than the complexity inherent in the problem, it may work. So if you see complex code handling many different edge cases, you can take that as an indicator the author understood the problem. That doesn't mean they do understand or that the solution does work; only that you have more confidence than you did initially.

It's a weak signal but the reasoning is sound.

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

#18

Post by adrr »

CamperBob2 wrote: post #3

Sheesh. Can something this complicated ever truly be said to work?

OS kernel runqueue is using a spinlock to schedule everything. So it works. Should you ever use a spinlock in application code? No. Let the OS via the synchronization primitives in whatever language your app is in.

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

#19

Post by direwolf20 »

wizzwizz4 wrote: post #15
kccqzy wrote: post #8

Earlier quoted context omitted.

Another time when writing a quick and dirty spinlock is reasonable is inside a logging library. A logging library would normally use a full-featured mutex, but what if we want the mutex implementation to be able to log? Say the mutex can log that it is non recursive yet the same thread is acquiring it twice; or that it has detected a deadlock. The solution is to introduce a special subset of the logging library to us…

I'm not sure how a spinlock solves this problem. Wouldn't that just cause the process to hang busy?

Only until the other thread leaves the logger

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

#20

Post by pyrolistical »

maxbond wrote: post #16
kelnos wrote: post #10

Earlier quoted context omitted.

That assertion feels suspiciously like a logical fallacy.

Not really. If the solution has less complexity than is inherent in the problem, it can't possibly work. If the solution has complexity equal to or greater than the complexity inherent in the problem, it may work. So if you see complex code handling many different edge cases, you can take that as an indicator the author understood the problem. That doesn't mean they do understand or that the solution does work; only…

Everything should be made as simple as possible, but not simpler.

Code has a minimum complexity to solve the problem

Post reply on HN