5 ms·
The author has an implicit definition of "faster" which it is important to be aware of. The main use of spinlocks that i'm aware of is minimising latency in in
by twic 7y ago
The author has an implicit definition of "faster" which it is important to be aware of.
The main use of spinlocks that i'm aware of is minimising latency in inter-processor communication.
That is, if you have a worker task which is waiting for a supervisor task to tell it to do something, then to minimise the time between the supervisor giving the order and the worker getting to work, use a spinlock.
For this to really work, you need to implement both tasks as threads pinned to dedicated cores, so they won't be preeempted. You will burn a huge amount of CPU doing this, and so it won't be "faster" from a throughput point of view. But the latency will be as low as it's possible to go.
- gpderetta 7y agoAlso if both threads are pinned to separate cores and nothing else is supposed to run on those cores, it is pointless to use anything but spinlocks as there is no other thread that could better use the core (and probably you do not want the core to go to a low power syate waiting for an interrupt).
- rumanator 7y ago> and nothing else is supposed to run on those cores That's quite the corner case.
- shaklee3 7y agoThis is the normal use case for any DPDK software. I think anyone involved in HPC or high-speed networking knows that this is pretty common.
- titzer 7y agoThis is exactly the situation for a well-balanced parallel work queue. You want to start as many threads as there are cores and run them full tilt pulling work off the queue until it is empty. If you're running a large scale cluster that is dedicated to a particular task (e.g. like servicing a special kind of query, or encoding videos, rendering, etc), this is very common, or even a parallel Photoshop filter.
- rumanator 7y ago> This is exactly the situation for a well-balanced parallel work queue. What if your work queues are running on a multitasking operating system that runs services? And what about a hypervisor?
- johncolanduoni 7y agoFor this technique you generally dedicate some core(s) to those miscellaneous threads and flag the rest as unscheduable unless a thread is specifically assigned to them. If you’re not sharing cores between VMs it’s typical to do the same at the hypervisor layer.
- gpderetta 7y agoYes, in practice you have to dedicate the whole machine for a specific application, but the one thread per isolated core is a proven one for high performance/low latency applications.
- jdblair 7y agoYou're discounting energy use. This is a bad strategy on a battery powered device.
- gpderetta 7y agoYes, you wouldn't use this strategy on a battery powered device. It ia for very specialised applications.
- corysama 7y agoIntel has a low-power PAUSE instruction that is literally a ‘rep nop’. I assume Arm has one too.
- temac 7y agoThat's not extremely low power compared to real low power states. The main advantage of PAUSE is the scheduling of the other hyperthread (if it exists) and maybe not generating a gratuitous L1 / MESI workload at a crazy rate (well if programmed correctly that should be quite cheap in lots of cases, but still...). To my knowledge this does not cut any clock, so the power economy is going to be minimal.
- dfox 7y agoIIRC the mov imm, %ecx; rep nop sequences are somewhat special cased by modern architectures (and this fact is the only reason why you even would want to execute such code). On the other hand the energy savings are mostly negligible and it is simply an SMT-level equivalent of sched_yield()
- gpderetta 7y agoActually I heard that the last few generations of intel (from skylake) enter power state mode more aggressively with pause and the latency of getting out of a pause went up from tens of cycles to hundreds. No first hand testing though.
- sephamorr 7y agoIn addition to energy, power use is another reason; parking a core will allow it to cool down thermally, so that when it is put back in use (milli)seconds later, it can run at a higher clock speed for longer.
- jakemal 7y agoWhat is a use case for optimizing interprocessor latency?
- lonelappde 7y agoFinishing a high priority job sooner.
- monocasa 7y agoLike TLB shootdown IPIs.
- anonymoushn 7y agoHello, I wrote some software at an automated trading firm that would do the subset of "parsing ticks and maintaining order books" sufficient to map ticks to symbols, and no more work than that. My code was pinned to one core and spun waiting for an expensive network card to DMA some ticks into memory, then when ticks we cared about were found it would load them onto one or more queues. Each queue corresponded to a different thread spin waiting on its own pinned core. So one use case is "transforming ticks into trading decisions slightly faster than you otherwise could"
- twic 7y agoComment-OP here - this is also more or less my use case. Whether there is a use case for spinlocks outside low-latency trading, i have no idea!
- anonymoushn 7y agoa friend of mine recently told me how Windows schedules cpu-bound threads to different cores to prevent thermal throttling, so I now wonder if we were mucking things up by running our CPUs too hot
- loeg 7y ago
- simias 7y ago>The main use of spinlocks that i'm aware of is minimising latency in inter-processor communication. The main use of spinlocks that I'm aware of is dealing with interrupt handlers in driver code. In this situation you generally can't go to sleep (sleeping with interrupts disabled is generally a good way of never waking up) so calling "mutex_lock" is simply out of the question. That's probably a niche use but that's literally the only situation I've ever used actual spin locks instead of mutexes, mainly for the reasons outlined by TFA.
- vba 7y agoTFA? Tried to google but unsuccessful
- wgjordan 7y agoThe (forementioned) article, I would imagine.
- hyperion2010 7y agoThe aForementioned Article the F is usually something else though ...
- axaxs 7y agoThe (Fuc|Frea)king Article. In a similar spirit to RTFM.
- ddebernardy 7y agoTFA is Slashdot jargon for "The F'ing Article".
- sillysaurusx 7y agoYa’ll should consider using atomic increment on separate cache lines instead of spinlocks. If you want to minimize latency to the bare minimum, atomic increment gives you two orders of magnitude measurable improvements over locks. https://lmax-exchange.github.io/disruptor/files/Disruptor-1.0.pdf https://lmax-exchange.github.io/disruptor/files/Disruptor-1....
- deleted 7y ago[deleted]
- extropy 7y agoAs far as I'm aware that's exactly how you would implement a spinlock. Random Google search seems to validate that. https://stackoverflow.com/questions/1383363/is-my-spin-lock-implementation-correct-and-optimal https://stackoverflow.com/questions/1383363/is-my-spin-lock-...
- sillysaurusx 7y agoCompare-and-swap isn't quite the same as atomic increment. An atomic increment can't fail; it always increments. Whereas CAS will fail if a different thread has modified the value. The highest performance design is to use a ringbuffer. To write to the ringbuffer, you atomic-increment the "claim" counter, giving you an index. Now take index modulo ringbuffer size. That's the slot to write to. After you're done writing to it, set your "publish" counter to the index. Each writer has a "publish" counter, and the "claim" counter isn't allowed to move beyond the lowest "publish" counter modulo ringbuffer size. Each reader uses a similar strategy: the reader has a current counter. You find the minimum of all publish counter values, then process each slot up to that value, and set your counter to that value. The "claim" counter isn't allowed to move past the minimum of all reader counters. Hence, everyone is reading from / writing to separate cache lines, and there are no locks at all. The sole primitive is atomic increment, which can never fail. (The only failure condition is "one of the slots hasn't been processed yet" (i.e. the publish counter is <= claim counter minus ringbuffer size) at which point everybody waits for the slot to be processed. You can wait using multiple strategies: a spin loop (which isn't the same as a spinlock because you're only reading a value in memory, not calling any atomic primitives), yielding CPU time via sched_yield(), or calling sleep. All strategies have tradeoffs. Calling sleep is the least CPU intensive, but highest latency. Vice-versa for spin loop. Takeaway: there are no locks. Just increments.
- Snelius 7y agoAbsolutely! spinlocks is an inter-processor mechanism and mutex inter-processes. Principal difference.