Spinlocks are more of an anti-pattern now than they used to be, as we have big.LITTLE type core configs, and hogging a P-thread with useless spinning can often bump the true bottleneck to an e-thread. Also, burning up CPU cores with spinning can eat into the turbo boosting budget.
We also now have the issue of cross-die latency absolutely nuking atomics, as seen with dual CCD ryzen CPUs. This one is actually major and why some apps run much slower on a 9950 versus a 9800.
Essentially, you really should try to make your algorithms work efficiently with mutexes first, with spinlocks saved as a last resort.
Spinlocks are more of an anti-pattern now than they used to be
I would argue spinlocks were more of an anti-pattern back when there was only one CPU core. You literally stopped anything from happening except interrupts.
They've been a huge anti-pattern since before there even was a term anti-pattern.
I agree with the last sentence. Although I would really say "blocking first", because that's the true alternative to spinlocks. Even spinlocks are basially a crummy form of mutexes.
Yeah, generally it was only done by people who were dumb as bricks.
Or, to be more fair, people who had no idea of systems programming. Which honestly is more and more people. Much more now than it was before. Systems are just so complex and programs so complex that few hold a top to bottom view. They might not even know their algorithm breaks down to a retry retry retry spin.
In any pattern where I'd have to use a spin lock instead of a mutex (e..g anything that needs realtime guarantees) I'd pin my threads to specific CPU cores anyways
A fantastic introductory explanation, learned a few things.
This kind of thing is why I generally try to use coroutines/green threads when possible, though there are unfortunately situations where going this low level is required.
Minor nitpick, but this specific verbiage always bothered me. It isn't that the implementation, or people who implemented it are smarter than you. It's more that they have been battle-tested for such a long time that you will likely lack the depth of experience to know all the edge cases that have been codified by these systems.
Effectively the same, don't overestimate your own capabilities, but it's not as detrimental as "you are dumber than they are."
Just a good article
Spinlocks are more of an anti-pattern now than they used to be, as we have big.LITTLE type core configs, and hogging a P-thread with useless spinning can often bump the true bottleneck to an e-thread. Also, burning up CPU cores with spinning can eat into the turbo boosting budget.
We also now have the issue of cross-die latency absolutely nuking atomics, as seen with dual CCD ryzen CPUs. This one is actually major and why some apps run much slower on a 9950 versus a 9800.
Essentially, you really should try to make your algorithms work efficiently with mutexes first, with spinlocks saved as a last resort.
I would argue spinlocks were more of an anti-pattern back when there was only one CPU core. You literally stopped anything from happening except interrupts.
They've been a huge anti-pattern since before there even was a term anti-pattern.
I agree with the last sentence. Although I would really say "blocking first", because that's the true alternative to spinlocks. Even spinlocks are basially a crummy form of mutexes.
Oh yea, spinlocking doing nothing when there isn't even another core to wait on was dumb as bricks.
It makes sense for an embedded controller polling some MMIO though.
Yeah, generally it was only done by people who were dumb as bricks.
Or, to be more fair, people who had no idea of systems programming. Which honestly is more and more people. Much more now than it was before. Systems are just so complex and programs so complex that few hold a top to bottom view. They might not even know their algorithm breaks down to a retry retry retry spin.
In any pattern where I'd have to use a spin lock instead of a mutex (e..g anything that needs realtime guarantees) I'd pin my threads to specific CPU cores anyways
A fantastic introductory explanation, learned a few things.
This kind of thing is why I generally try to use coroutines/green threads when possible, though there are unfortunately situations where going this low level is required.
[removed]
Minor nitpick, but this specific verbiage always bothered me. It isn't that the implementation, or people who implemented it are smarter than you. It's more that they have been battle-tested for such a long time that you will likely lack the depth of experience to know all the edge cases that have been codified by these systems.
Effectively the same, don't overestimate your own capabilities, but it's not as detrimental as "you are dumber than they are."
nice ai generated comment
Reading this makes me questioning myself about programming. Feel bad man
Don’t worry about it, it’s a robot
Just don't be casual when doing these things. Super careful time.
P.S. lock files are still a thing, kinda yikes.