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

81–90 of 150 posts

Re: Mutexes are faster than Spinlocks

#81

Post by gpderetta »

simias wrote: post #75
NeedMoreTea wrote: post #67

Earlier quoted context omitted.

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.

The original, as documented in the hacker dictionary, is of course RTFM (read the f...ine manual).

Re: Mutexes are faster than Spinlocks

#82

Post by codezero »

simias wrote: post #75
NeedMoreTea wrote: post #67

Earlier quoted context omitted.

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.

Not sure it’s the origin, but it used to be RTFM (read the fucking manual).

Re: Mutexes are faster than Spinlocks

#83

Post by [deleted] »

sillysaurusx wrote: post #70
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…

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

[deleted]

Re: Mutexes are faster than Spinlocks

#84

Post by gpderetta »

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

Liquid cooling is not unheard of in the low latency trading world.

Re: Mutexes are faster than Spinlocks

#85

Post by sjwright »

codezero wrote: post #82
simias wrote: post #75

Earlier quoted context omitted.

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.

Not sure it’s the origin, but it used to be RTFM (read the fucking manual).

RTFM has been mostly superseded by LMGTFY.

Re: Mutexes are faster than Spinlocks

#87

Post by temac »

kcolford wrote: post #14

This absolutely makes sense in userspace. The most important part of a spinlock in an OS is that you can yield to the scheduler instead of taking up CPU time on the core. But that defeats the purpose of using a spinlock when in userspace because you still have to syscall

A spinlock in the kernel typically only spins. You use it for the cases when you can't schedule... So it better will be for a short time only.

But the concept of short time does not even exist deterministically in userspace, usually, because it can always be preempted. So don't use pure spinlocks in userspace, unless you really really know what you are doing (and that includes knowing how your kernel works in great details, in the context of how you use it).

Re: Mutexes are faster than Spinlocks

#88

Post by sephamorr »

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.

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

Re: Mutexes are faster than Spinlocks

#89

Post by temac »

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

Does it really sleep for a specified period instead of doing directed wake-ups? If so that's very far from ideal...

Re: Mutexes are faster than Spinlocks

#90

Post by gpderetta »

elteto wrote: post #9
hackworks wrote: post #2

Not an expert here. In a spin lock, the lock state is checked in a tight loop by all waiters. This will be using some sort of memory fence. FWIK, memory fence or barriers flush the CPU cache and would initiate reading the variable (spin lock state) for evaluation. I would expect spin locking overheads to increase with number of cores. On NUMA, I think flushing is more expensive. Hence, spin locks have an additional o…

> checked in a tight loop by all waiters This actually does not have to be this way. You could have a linked list of spinlocks, one for each waiter. Each waiter spins on its own, unique spinlock. When the previous waiter is done it unlocks the next spinlock, and so on. The implementation gets a bit complicated on non-GC languages, since there are races between insertion/removal on the linked list. If the number of th…

> you could possibly do away atomics, since (I believe) int updates are atomic by default.

The release can be a compiler only barrier followed by a simple store, but you do need an atomic RMW in the acquire path.

It is technically possible to implement a lock with just loads and stores (see Peterson lock[1]) even in the acquire path but it does require a #StoreLoad memory barrier even on Intel, which is as expensive as an atomic RMW so it is not worth it.

Edit:fixed barrier name typo.

[1] https://en.m.wikipedia.org/wiki/Peterson%27s_algorithm

Post reply on HN