2

It seems that spinlocks aren't that great as they waste CPU cycles when the are waiting (blocking). If the thread just goes to sleep while waiting for a signal to wakeup, then CPU cycles aren't lost while spinning.

Maybe it is good to use a spinlock if the locks are held for a very short time, then maybe it uses less time? If this is true why?

Bobby S
  • 4,006
  • 9
  • 42
  • 61
  • You might want to check out the wikipedia entry (http://en.wikipedia.org/wiki/Spinlock) on this topic. It seems very informative. :) – gbvb Feb 17 '11 at 04:02

3 Answers3

3

Yes, that's correct.

Because context switches are expensive. The OS and CPU have to do a (relatively) large amount of work to perform a context switch. Spinning for a few cycles instead will be a lot cheaper, even if those cycles are, in theory, wasted.

LukeH
  • 263,068
  • 57
  • 365
  • 409
3

Spinlocks are faster when they do not block, which is why they are useful in situations where there is very low contention in the lock (ie a very low chance it is already locked).

When a thread sleeps it cause a context switch (ie, this thread gets swapped out for another so that the other thread may run). There is also usually higher overhead to acquiring a standard mutex than there is for checking if a spinlock is free. Very often spinlocks only require a single atomic operation when the lock is free.

These properties make spinlocks useful for fine grained locking, since using smaller locks decreases the contention on each lock. For example, one of my projects has a map with ~200,000 entries being accessed by 16+ threads at the same time (enterprise server type of thing). Having a spinlock per entry is fairly efficient because the chance that two threads in this app try to hit the same entry at the same time is low.

Chris Pitman
  • 12,990
  • 3
  • 41
  • 56
1

Spinlocks allow for tight polling and faster wakeups when lock becomes available. They are also good for non-contended locks as @Chris pointed out. I would say use spin locks:

  1. If all you care about is performance of your own application, and don't want to yield to the other apps and your app has <= threads than the number of cores. I would still consider ticket locks to optimize for cache misses however... they also spin but reduce cache misses a lot.

  2. or, if your locks are less contended

Aater Suleman
  • 2,286
  • 18
  • 11
  • Best answer, I think, for being the only answer that mentions the need to have more CPU cores than application threads for spinlocks to be worth it. Since obviously if for example you have only one CPU core, a contested spinlock will spin until the hardware interrupt that the OS scheduler set up fires and the OS context switches to running the other thread that holds the lock. Increasing the number of cores decreases the odds, but it's only when you have enough cores to not spinlock all of them that a contested spinlock stops being a guaranteed spin-until-system-forces-a-context-switch-anyway. – mtraceur Nov 13 '22 at 22:39