4 ms·
A typical mutex has essentially two very different costs depending on whether the lock is already taken by another thread: - Uncontended case + mutex: no sysca
by p0nce 7y ago
A typical mutex has essentially two very different costs depending on whether the lock is already taken by another thread:
- Uncontended case + mutex: no syscall, fast path is basically the cost of the memory barrier.
- Uncontended case + spinlock: no syscall, fast path is basically the cost of the memory barrier. Essentially same cost than a mutex, sometimes a tiny bit cheaper but _if your lock isn't contented in the first place it will be very hard to measure, since not being a bottleneck_.
- Contended case + mutex: thread is waiting in the mutex list without taking CPU. Hyper-threading may also give hand immediately to another thread, perhaps lucky enough to run. The OS mutex may have a bit of capped spinning before waiting in the scheduler.
- Contended case + spinlock: Anything goes. CPU gets consumed just for spinning. Wrong thread might get priority. If you are lucky you did put a HLT instruction to mitigate the complete disaster that spinlocks are, perhaps it even does something. Your consolation: no syscall or thread pausing... because they are spinning.
tl;dr: spinlock are worse in the contended case and essentially the same performance in the uncontended case against your typical OS mutex. SPINLOCKS WON'T YIELD THE EXPECTED BENEFITS, USE REGULAR OS MUTEXES.
- ketzu 7y agoI believe the supposed beneficial case of blocking vs spinning can't be captured well by those categories, as it's "contended, but not for long" and "contended, but for longer". That's the reason for the "may have a bit of capped spinning before waiting in the scheduler".
- p0nce 7y agoHonestly I'm not so sure about the case for spinning; in x264 source you can see CRITICAL_SECTION is tuned to have a spincount of 0. This is a very optimized, multi-threaded app. They didnt want any spinning. https://github.com/mirror/x264/blob/d4099dd4c722f52c4f3c14575d7d39eb8fadb97f/common/win32thread.c#L47 https://github.com/mirror/x264/blob/d4099dd4c722f52c4f3c1457... In my own attempts I've been unable to measure the impact of the spinlock count, and took spincount = 40 like in https://trac.webkit.org/browser/webkit/trunk/Source/WTF/wtf/Lock.cpp?rev=200444#L44 https://trac.webkit.org/browser/webkit/trunk/Source/WTF/wtf/... ...who also took measurement from elsewhere. The default is 4000 on Windows! I don't argue spinning isn't valuable ; what I say is that it's necessarily never the bottleneck (else your task size really is too small). After all, if you spend all your time in synchronization, that means you probably need to have bigger tasks, not more clever synchronization primitives.
- temac 7y agoBesides OS where they are often needed, spinlocks can have their place in a few very specific (and most of the time isolated on dedicated computers), but I agree that too many people are trying to play with them now, without enough knowledge.
- gpderetta 7y agoA problem with pthread mutex and std::mutex is that they are often very large which is problematic for very fine grained locking, while you only need one bit for a spin lock and can be embedded in other objects (say, a pointer) as long as you can spare one bit. Of course you can roll your own proper mutex if you want to get your hands dirty with futexes. IIRC you only need two bits (one waiter bit and one locked bit).
- shaklee3 7y agoNot sure what you mean by a single bit for a spin lock. It's a cas operation, which doesn't operate on a single bit. Edit: I think I see what you're getting at, but the point from the article about cache invalidation for the naive implementation still is valid.
- Matthias247 7y agoYou can do it with a single bit: Read the whole unit (eg 64 bit), flip the big you need, and then do a Compare exchange which tries to replace the whole retrieved thingy with the modified one. That obviously requires you to read the current state upfront, whereas a plan compare exchange from 0 to 1 on 32/64Bit avoids that.
- p0nce 7y agoThat doesn't work since this isn't atomic anymore.
- gpderetta 7y agoOf course it is. The mutating operation is the CAS which requires the existing value anyway.
- p0nce 7y agoMmmm... I had to write this down. 0: CAS_bit_n(void* adr, int n) 1: while(true): 2: old <- read unit(adr) 3: new <- compute-new-value-with-changed-bit-n(old, n) 4: if CAS(adr, old, new): 5: break 6: else 7: continue Indeed it seems it is correct if you retry.