I'm really curious how macOS's os_unfair_lock compares here.
Is that implementation open source? Don’t remember which dyld contains it.
Mutexes are faster than Spinlocks
61–70 of 150 posts
Re: Mutexes are faster than Spinlocks
#62The 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 real…
>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 l…
TFA? Tried to google but unsuccessful
Re: Mutexes are faster than Spinlocks
#63Earlier quoted context omitted.
>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 l…
TFA? Tried to google but unsuccessful
The (forementioned) article, I would imagine.
Re: Mutexes are faster than Spinlocks
#64Earlier quoted context omitted.
>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 l…
TFA? Tried to google but unsuccessful
The aForementioned Article
the F is usually something else though ...
Re: Mutexes are faster than Spinlocks
#65Earlier quoted context omitted.
>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 l…
TFA? Tried to google but unsuccessful
The (Fuc|Frea)king Article. In a similar spirit to RTFM.
Re: Mutexes are faster than Spinlocks
#66Earlier quoted context omitted.
>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 l…
TFA? Tried to google but unsuccessful
TFA is Slashdot jargon for "The F'ing Article".
Re: Mutexes are faster than Spinlocks
#67Earlier quoted context omitted.
>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 l…
TFA? Tried to google but unsuccessful
I've seen lots of valid variants, including and probably not limited to:
The feature article ; the freaking article ; the friendly article ; the f$%^&*( article, c.f. RTFM.
Re: Mutexes are faster than Spinlocks
#68Earlier quoted context omitted.
Also 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).
You're discounting energy use. This is a bad strategy on a battery powered device.
Yes, you wouldn't use this strategy on a battery powered device. It ia for very specialised applications.
Re: Mutexes are faster than Spinlocks
#69Earlier quoted context omitted.
>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 l…
TFA? Tried to google but unsuccessful
The Fine Article.
Re: Mutexes are faster than Spinlocks
#70The 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 real…
Ya’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....