4 ms·
> Just don't use any shared state, bro Thank you, Sherlock. But for the rest of us: when you need shared state, lockfree atomic spinlocks are roughly 1000 tim
by otabdeveloper4 3y ago
> Just don't use any shared state, bro
Thank you, Sherlock.
But for the rest of us: when you need shared state, lockfree atomic spinlocks are roughly 1000 times more performant than mutexes. (Not a scientific estimate, numbers taken from real-word experience.)
- petters 3y ago> spinlocks are roughly 1000 times more performant than mutexes That is absolutely not universal. See e.g. but there are of course many places discussing this: https://news.ycombinator.com/item?id=21970050 https://news.ycombinator.com/item?id=21970050
- saagarjha 3y agoLocking is hard in general. Don’t do an unbounded spin in userspace is typically good advice though. The typical mutex construction these days will spin for a little while in an attempt to take advantage of mostly uncontended locks and then yield to the kernel.
- happymellon 3y agoThis immediately popped into my head too when I saw the comment. Spinlocks are terrible, and written by people who are trying to do quick hacks because they work in terrible environments and are taught to do bad things. There is a reason that most GPU drivers are just lists of hacks to get games working correctly.
- imtringued 3y agoYeah, spinlocks sound cool but actually they are terrible. Hybrid locks are generally quite good. The only way to get better is to pin cores and let nothing else run on them. Only then will spinlocks have a chance to increase performance by a tiny bit.
- Ono-Sendai 3y agomutexes are not that slow. Uncontested (single thread): incrementing using atomics took 0.002011 s (0.2513 ns / increment) incrementing using mutex took 0.005515 s (0.6894 ns / increment) Contested (8 threads trying to increment a single protected integer): incrementing using atomics took 0.1069 s (13.36 ns / increment) incrementing using mutex took 1.970 s (246.3 ns / increment) So mutexes are roughly the same speed in the uncontested case, and about 20x slower in this heavily contested case. This is on Windows.
- cyberax 3y agoI guess you have more than 8 physical CPUs?
- Ono-Sendai 3y ago16 cores
- mjan22640 3y agoIs that AMD or Intel? Intel ivalidates the other CPU's cache line on write. AMD sends an update to the other CPU's cache line. AMD is supposed to be significantly faster than Intel on a "real" multiprocessor workload.
- Ono-Sendai 3y agoAMD Ryzen 9.
- ComputerGuru 3y agoDon’t know why you were downvoted but yes, AMD uses MOESI and Intel uses MESI.
- cyberax 3y agoNo, they are not. The slow part of locking is invalidation of cache lines, and this has to happen with spinlocks anyway. Modern mutex implementations also first try to acquire the lock optimistically, so in the uncontended case they are as fast as userspace spinlocks (modulo inlining). And if you have a contended lock, then userspace spinlocks are a PITA. You need to take care of fairness, ideally deal with the scheduler (yield to a thread that is not spinning on the same spinlock), and so on. You can do all of that properly, but even then, you're looking at maaaaybe 10-20% performance increase in real-world applications. Pure spinlocks can win only in contrived cases, like only having exactly two threads contending for the lock, with short locked sections.
- saagarjha 3y agoPure spin locks will always win for uncontended locks.
- NobodyNada 3y agoWithout any contention at all, a spinlock and a mutex are identical: a single compare-and-swap.
- gpderetta 3y agoTechnically you can use a release-store on a spinlock unlock path, but you need a CAS for a mutex.
- mangamadaiyan 3y ago>userspace spinlocks are a PITA ... >ideally deal with the scheduler Don't you anyway need to drop the scheduler a hint so that the thread holding the spinlock doesn't get scheduled off the CPU, making the contenders wait longer than they ideally should? (Or is this what you meant by your "fairness" reference?) In my limited understanding, this was the no. 1 reason why userspace spinlocks were discouraged -- because pretty much no scheduler accepted a hint from userspace to not kick a thread off the CPU -- modulo jumping through hoops with priority, et cetera. If I'm missing something (and I likely am), I would be glad to be educated.
- gnulinux 3y agoThis is not true, you should never use spinlocks in userspace unless you know exactly what you're doing. Using spinlocks well requires scheduling, which you have no control over in userspace, this is why it makes more sense for kernel to use spinlocks. Without scheduling, with spinlocks, random threads can starve for no reason.
- otabdeveloper4 3y agoYou are right, theoretically. Unfortunately, the userspace part of pthreads is not tuned for performance and does a lot of ridiculous things if you care about parallelism. (Mostly I was complaining about the poor quality of userspace system libraries.)