15

What are the basic differences between spin locks and semaphores in action?

Improve this question
5

3 Answers 3

Reset to default
13

Both manage a limited resource. I'll first describe difference between binary semaphore (mutex) and spin lock.

Spin locks perform a busy wait - i.e. it keeps running loop:

while (try_acquire_resource ());
...
release();

It performs very lightweight locking/unlocking but if the locking thread will be preempted by other which will try to access the same resouce the second one will simply try to acquitre resource untill it run out of it CPU quanta.

On the other hand mutex behave more like:

if (!try_lock()) {
    add_to_waiting_queue ();
    wait();
}
...
process *p = get_next_process_from_waiting_queue ();
p->wakeUp ();

Hence if the thread will try to acquire blocked resource it will be suspended till it will be avaible for it. Locking/unlocking is much more heavy but the waiting is 'free' and 'fair'.

Semaphore is a lock that is allowed to be used multiple (known from initialization) number of times - for example 3 threads are allowed to simultainusly hold the resource but no more. It is used for example in producer/consumer problem or in general in queues:

P(resources_sem)
resource = resources.pop()
...
resources.push(resources)
V(resources_sem)
Improve this answer
5
  • Good explanation, I just want to emphasize one point. Semaphore vs mutex is a matter of interface: a mutex is held or not, while a semaphore is held by up to N threads; a mutex is a special case of semaphores with N=1. Spinlock vs other kind of lock is a matter of implementation: a spinlock keeps trying to acquire the lock, whereas other kinds wait for a notification. In a Linux kernel context, the only lock with a spin implementation has a mutex interface.
    – Gilles 'SO- stop being evil'
    Dec 29, 2010 at 19:33
  • In a Linux kernel context, the only lock with a spin implementation has a mutex interface. I dint understand this line. Could you please expand on it?
    – Navaneeth Sen
    Jan 2, 2011 at 15:56
  • @Sen: He meant that spin lock in Linux behave binary (it is locked or not). It is possible to have a spinning lock behaving as semaphor.
    – Maja Piechotka
    Jan 2, 2011 at 20:39
  • “but if the locking thread will be preempted by other which will try to access the same resouce the second one will simply try to acquitre resource untill it run out of it CPU quanta.” : but an issue still remains with Mutex too. What if the a task with more priority needs to access the resource… is it just queued? May be it's better to void sharing resources between tasks with different priorities.
    – Hibou57
    Jul 30, 2013 at 0:35
  • @Hibou57: Yes it is blocked as the state is not consistent and using the resource would have 'funny' effects (say the low priority thread was in the middle of adding or removing something to/from linked list). The point of this statement was that if thread is blocked it is not scheduled so it does not consume resources while thread waiting on spinlock does. Locking for real-time systems (especially hard) is different topic and I don't have sufficient knowledge to answer it - however those system sometimes implement priority donations or other techniques.
    – Maja Piechotka
    Jul 30, 2013 at 8:27
2

Spinlocks are used in an interrupt context, where sleeping is not allowed. They poll in a tight loop, doing nothing else until the resource is acquired. Mostly used in ISRs, and more secure and efficient.

Semaphores can be used in a process context, where sleeping is ok.

Improve this answer
1

Here's my quick shot at an answer: a spin lock and a binary semaphore (which manages a resource that can only be used by one thing) are almost identical. Their distinction is that spin locks manage code to be run while binary semaphores manage some kind of singular resource (e.g. cpu time, display output)

A regular semaphore, however is able to manage several threads accessing a resource that can be split among several, but is limited (e.g. memory, network bandwidth)

In short, a spin-lock is likely to keep asking a semaphore if it can use a resource. (Imagine a child having to use the bathroom and waiting for someone else to finish.)

Sources: Introduction to Systems Programming, Operating Systems, and wikipedia

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .