What is the basic differences between Semaphores & Spinlock? & In what best situations or conditions, we can use these.
+20
A:
very simply, a semaphore is a "yielding" synchronisation object, a spinlock is a 'busywait' one. (there's a little more to semaphores in that they synchronise several threads, unlike a mutex or guard or monitor or critical section that protects a code region from a single thread)
You'd use a semaphore in more circumstances, but use a spinlock where you are going to lock for a very short time - there is a cost to locking especially if you lock a lot. In such cases it can be more efficient to spinlock for a little while waiting for the protected resource to become unlocked. Obviously there is a performance hit if you spin for too long.
typically if you spin for longer than a thread quantum, then you should use a semaphore.
gbjbaanb
2008-10-12 19:06:02
+2
A:
Spinlock refers to an implementation of inter-thread locking using machine dependent assembly instructions (such as test-and-set). It is called a spinlock because the thread simply waits in a loop ("spins") repeatedly checking until the lock becomes available (busy wait). Spinlocks are used as a substitute for mutexes, which are a facility supplied by operating systems (not the CPU), because spinlocks perform better, if locked for a short period of time.
A Semaphor is a facility supplied by operating systems for IPC, therefor it's main purpose is inter-process-communication. Being a facility supplied by the operating system it's performance will not be as good as that of a spinlock for inter-thead locking (although possible). Semaphores are better for locking for longer periods of time.
That said - implementing splinlocks in assembly is tricky, and not portable.
yoav.aviram
2008-10-12 19:18:32
All multi-threading CPUs need a spinlock instruction ("test and set") and it's always implemented as a single instruction in hardware because there would otherwise always be a race condition in which more than one thread thought it "owned" the protected resource.
Richard T
2008-10-12 19:33:35
I'm not sure you understand semaphores... see what Dijkstra said: http://www.cs.cf.ac.uk/Dave/C/node26.html
gbjbaanb
2008-10-12 19:52:40
POSIX makes a distinction between a semaphore shared by threads, and a semaphore shared by processes.
Greg Rogers
2008-10-12 20:19:35
+4
A:
Over and above what Yoav Aviram and gbjbaanb said, the other key point used to be that you would never use a spin-lock on a single-CPU machine, whereas a semaphore would make sense on such a machine. Nowadays, you are frequently hard-pressed to find a machine without multiple cores, or hyperthreading, or equivalent, but in the circumstances that you have just a single CPU, you must use semaphores. (I trust the reason is obvious; if the single CPU is busy waiting for something else to release the spin-lock, but it is running on the only CPU, the lock is unlikely to be released.)
Jonathan Leffler
2008-10-12 19:53:01
I'd like to second how important it is not to use spinlocks on single threaded systems. They are a the ticked to priority inversion problems. And trust me: You don't want to debug these kind of bugs.
Nils Pipenbrinck
2008-10-12 20:06:20
spinlocks are all over in the Linux kernel, regardless if you have one ore more CPUs. What do you mean exactly?
Amigable Clark Kant
2010-05-07 10:24:42
@Amigable: by definition, a spinlock means that the current thread on the CPU is waiting for something else to release the locked object. If the only active thing that can change the lock is the current CPU, the lock will not be freed by spinning. If something else - a DMA transfer or other I/O controller can release the lock, all well and good. But spinning when nothing else can release the lock is not very sensible - you might as well yield the CPU to another process now as wait to be preempted.
Jonathan Leffler
2010-05-07 14:46:40
@Jonathan Leffler, I may very well be wrong, but I was under the impression that a re-entrant (single CPU) Linux kernel may interrupt a running spin lock.
Amigable Clark Kant
2010-05-10 12:29:57
@Amigable: there's a chance I'm wrong too, but I think I'm close to the classic definition of a spinlock. With pre-emptive scheduling, a process might spin on a lock until the end of its time slice, or until an interrupt causes it to yield, but if another process must provide the condition that allows the spinlock to lock, a spinlock is not a good idea on a single CPU machine. The system I work on has spinlocks and has a configurable upper bound on the number of spins before it goes into a non-busy wait mode. This is a user-level spin-lock; there might be a difference down in the kernel.
Jonathan Leffler
2010-05-10 13:18:48
+1
A:
I am not a kernel expert but here are few points:
Even uniprocessor machine can use spin-locks if kernel preemption is enabled while compiling the kernel. If kernel preemption is disabled then spin-lock (perhaps) expands to a void statement.
Also, when we are trying to compare Semaphore vs Spin-lock, I beleive semaphore refers to the one used in kernel - NOT the one used for IPC (userland).
Basically, spin-lock shall be used if critical section is small ( smaller then the overhead of sleep/wake-up) and critical section does not call anything that can sleep!. A semaphore shall be used if critical section is bigger and it can sleep.
Raman Chalotra.
Raman Chalotra
2010-06-21 18:47:29