2

I know spin lock only works on multiprocessor. But if two threads try to acquire the same resource and one is put on spinlock, what prevents the other one not running on the same processor? If it happens the one with spin lock will prevent the one holding the resources to exceed. In this case it becomes a deadlock. How does OS prevent it happen?

Cœur
  • 37,241
  • 25
  • 195
  • 267
user2900385
  • 21
  • 3

1 Answers1

3

Some background facts first:

  • spin-locks (and locks generally) are not limited to multiprocessor systems. They work fine on single processor or even single-threaded application can use them without any harm.
  • spin-locks are not only provided by OS, they have pure user-space implementation as well. For example, provides tbb::spin_mutex.
  • By default, nothing prevents a thread from running on any available CPU (regardless of the locks they use).
  • There are reentrant/recursive type of locks. It means that if a thread acquired it once, and tries to acquire it once again without releasing, it will succeed, not deadlock as usual locks. But it does not mean that the same applies to different threads just because they are scheduled to the same CPU. With any type of lock, if one software thread locked a mutex, other threads have to wait.

It is possible for one thread to acquire the lock and be preempted (i.e. interrupted by OS timer) before it releases the lock. Another thread can be scheduled to the same CPU and it might want to acquire the same lock. In case of pure spin-locks, this thread will uselessly spin until it exceeds its time-slice allowed by OS and will be preempted. Finally, the first thread will get a chance to run and release its lock so another thread will be able to acquire it.

As you can see, it is not quite efficient to spent the time on the hopeless waiting. Thus, more sophisticated implementations, after a number of attempts to acquire the spinlock, call OS for help in order to voluntary give away its time-slice to other threads which possibly can unlock the current one.

Anton
  • 6,349
  • 1
  • 25
  • 53
  • Thanks Anton! As you said spin lock for uniprocessor works but not effective. On the multi core system it makes more sense for one thread spin to wait the other thread running to release the lock. If the other thread is not running it is better to use mutex. It is adaptive mutex in Solaris. If I don't have an OS like Solaris when I use spinlock on multi processor system I guess it is the user's responsibility to check the other thread holding the lock is not running on the same core or sleeping. Because if it is the case a mutex will be more efficient. – user2900385 Aug 20 '14 at 17:41
  • pthread_mutex is adaptive on Linux (at least) as well: it first tries to get lock in user mode and then go to OS. And as I said, if after several attempts the lock is not acquired, a spinlock can call the OS. Checking the state of another thread seems heavy and likely calls OS anyway which ruins the benefits of a spinlock. – Anton Aug 20 '14 at 17:48
  • I doubt there's any serious mutex implementation out there that doesn't spin for a few cycles or so. Kernel calls are expensive and most locks are uncontended. Windows critical sections do the same. On the same note, I doubt you can check other thread's state from user code so doing that "optimization" would remove all the reasons for spin locks in the first place. – Voo Aug 20 '14 at 19:38
  • @user2900385, you might want to accept/upvote the answer if it helps, thanks :) – Anton Aug 22 '14 at 10:44