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

Mutexes are faster than Spinlocks

matklad.github.io

Post reply on HN
Print view View original

71–80 of 150 posts

Re: Mutexes are faster than Spinlocks

#71

Post by loeg »

anonymoushn wrote: post #57
twic wrote: post #54

Earlier quoted context omitted.

Comment-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!

a 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

If you weren't pegging thermal max you shouldn't be seeing thermal limiting. Although you're probably right that cooling is something software people are more likely overlook than SRE/hardware/lab folks.

Re: Mutexes are faster than Spinlocks

#73

Post by ww520 »

acqq wrote: post #58
ww520 wrote: post #37

Earlier quoted context omitted.

It seems to be doing similar logic. 1. Does a CAS with compare_exchange_weak() at line 69. 2. Then call lock_slow() at line 72 to do spinlocking (Guh!). 3. The call to parking_lot_core::park() at line 256 seems to sleep wait.

So this it acquires fully in userspace if there's no contention, it even spins if there is contention, and then if that wasn't enough it lets the thread sleep with the timeout. Which matches the description of that library: https://github.com/Amanieu/parking_lot "This library provides implementations of Mutex, RwLock, Condvar and Once that are smaller, faster and more flexible than those in the Rust standard library"…

Ah, thanks for the info.

I would imagine the unlocking call would wake up the sleeping thread so it won't keep waking up periodically.

The user-mode only implementation sounds interesting. The only downside is it won't work with inter-process locking.

Re: Mutexes are faster than Spinlocks

#74

Post by corysama »

jdblair wrote: post #60
gpderetta wrote: post #38

Earlier 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.

Intel has a low-power PAUSE instruction that is literally a ‘rep nop’. I assume Arm has one too.

Re: Mutexes are faster than Spinlocks

#75

Post by simias »

NeedMoreTea wrote: post #67
vba wrote: post #62

Earlier quoted context omitted.

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.

I personally go with "The Fine Article" in my mind when I write it, although obviously all these alternatives are possible. I first encountered this initialism on slashdot back when it was still relevant, although I don't know if it was coined there.

And yeah, I believe that it derives from "RTFA" (read the fucking article) which would be what you told people who obviously commented without reading the article.

Re: Mutexes are faster than Spinlocks

#76

Post by gpderetta »

rwem wrote: post #41
gpm wrote: post #33

Earlier quoted context omitted.

You're misreading the benchmark, that's 6ms for 10,000 lock/unlocks per thread, 320,000 lock/unlocks total. In other words 0.6 microseconds per thread per lock.

That's still unreasonably high, isn't it? Even a Go sync.Mutex, not exactly a hot-rod implementation, can be acquired and released in < 50ns on the garbage hardware I have before me.

On Intel (and probably very similar on AMD) the cost of a completely uncontented, cache hit, simple spin lock acquisition is ~20 clock cycles while the release is almost free.

Re: Mutexes are faster than Spinlocks

#77

Post by trasz »

simias wrote: post #56
twic wrote: post #27

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 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…

And even that is only true for systems that don’t use interrupt threads.

Re: Mutexes are faster than Spinlocks

#78

Post by temac »

corysama wrote: post #74
jdblair wrote: post #60

Earlier quoted context omitted.

You're discounting energy use. This is a bad strategy on a battery powered device.

Intel has a low-power PAUSE instruction that is literally a ‘rep nop’. I assume Arm has one too.

That'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.

Re: Mutexes are faster than Spinlocks

#79

Post by [deleted] »

ww520 wrote: post #73
acqq wrote: post #58

Earlier quoted context omitted.

So this it acquires fully in userspace if there's no contention, it even spins if there is contention, and then if that wasn't enough it lets the thread sleep with the timeout. Which matches the description of that library: https://github.com/Amanieu/parking_lot "This library provides implementations of Mutex, RwLock, Condvar and Once that are smaller, faster and more flexible than those in the Rust standard library"…

Ah, thanks for the info. I would imagine the unlocking call would wake up the sleeping thread so it won't keep waking up periodically. The user-mode only implementation sounds interesting. The only downside is it won't work with inter-process locking.

[deleted]
Post reply on HN