Sheesh. Can something this complicated ever truly be said to work?
Yes, if you're careful. Actually careful, not pretend careful. Which is pretty normal in C and C++.
Spinning around: Please don’t – Common problems with spin locks
21–30 of 66 posts
Re: Spinning around: Please don’t – Common problems with spin locks
#22i always got the sense that spinlocks were about maximum portability and reliability in the face of unreliable event driven approaches. the dumb inefficient thing that makes the heads of the inexperienced explode, but actually just works and makes the world go 'round.
Re: Spinning around: Please don’t – Common problems with spin locks
#23The 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…
I wrote my own spin lock library over a decade ago in order to learn about multi threading, concurrency, and how all this stuff works. I learned a lot!
Re: Spinning around: Please don’t – Common problems with spin locks
#24Earlier quoted context omitted.
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
Oh, I see: the spinlock is for logging the deadlocks of other mutices, not for magically remediating deadlocks.
Re: Spinning around: Please don’t – Common problems with spin locks
#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 lfence (previously cpuid) can be used and there is also rdtscp
See https://github.com/torvalds/linux/blob/master/arch/x86/inclu...
And just because rdtsc is constant doesn't mean the processor clock will be constant that could be fluctuating.
Re: Spinning around: Please don’t – Common problems with spin locks
#26"Unfair" paragraph is way too short. This is the main problem! The outlier starvation you get from contended spinlocks is extraordinary and, hypothetically, unbounded.
Well, you need to have specified what you actually want. "Fair" sounds like it's just good, but it's expensive, so unless you know that you need it, which probably means knowing why, you probably don't want to pay the price.
Stealing is an example of an unfairness which can significantly improve overall performance.
Re: Spinning around: Please don’t – Common problems with spin locks
#27TFA 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.
Re: Spinning around: Please don’t – Common problems with spin locks
#28Earlier 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. A different place to look for this is in chemical reactions and things biological life does.
You may have some simple chemical life needs, and life may have some other simple chemical it can use to get the needed simple chemical, but the processing steps are complex and limited by physics themselves. Evolution almost always finds a path of using the minimum activation energy to let these reactions occur. Trying to make the process simpler just doesn't get you what you need.
Re: Spinning around: Please don’t – Common problems with spin locks
#29Nice article! Yes, using spinlocks in normal userspace applications is not recommended.
One area where I found spinlocks to be useful is in multithreaded audio applications. Audio threads are not supposed to be preempted by other user space threads because otherwise they may not complete in time, leading to audio glitches. The threads have a very high priority (or have a special scheduling policy) and may be pinned to different CPU cores.
For example, multiple audio threads might read from the same sample buffer, whose content is occasionally modified. In that case, you could use a reader-writer-spinlock where multiple readers would be able to progress in parallel without blocking each other. Only a writer would block other threads.
What would be the potential problems in that scenario?
Re: Spinning around: Please don’t – Common problems with spin locks
#30The 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 somewhat known case of a spinlock is in trading, where for latency purposes the OS scheduler is essentially bypassed by core isolation and thread pinning, so there’s nothing better for the CPU to do than spinning.