spin_lock - comp.lang.c

InuY4sha wrote: > Can anybody give me the basics (or a *basic* instructions link) > regarding spinlocks and their usage? I really can't understand their > meaning... http://en.wikipedia.org/wiki/Spin_lock -- Thad

On 9 Apr 2008 at 13:12, Thad Smith wrote: > InuY4sha wrote: >> Can anybody give me the basics (or a *basic* instructions link) >> regarding spinlocks and their usage? I really can't understand their >> meaning... > > http://en.wikipedia.org/wiki/Spin_lock That article seems to focus more on implementing spinlocks than on using them... A spinlock has the same function as a mutex: they're both mutual exclusion locks. The only difference is the behavior when a thread tries to gain a lock, but the lock is already held by another thread. If a mutex is held by another thread, the current thread is suspended and doesn't resume until it can gain the lock. If a spinlock is held by another thread, the current thread is still scheduled as normal, but will go into a loop which tries to gain the lock on each iteration. So a mutex is a sort of passive thing - the thread does nothing until the mutex is available - while for a spinlock, the thread proactively tries to gain the lock whenever it can get processor time. The main advantage of spinlocking is /potential/ speed gain - if the time needed for the lock to become available is less than the time needed for context switching, then obviously this will save time. The disadvantage is that if it takes a long time for the lock to become available, then because the waiting thread uses up all of its time slice processing the infinite lock-trying loop, this will slow down other threads. And of course, on a single core machine, spinlocking can only hurt you, since other threads can only run (and therefore the lock sought can only be released) after a context switch anyway. In summary, spinlocks are useful in a very small number of specific situations, which are speed critical (every tick counts) and where the lock is held to protect a small number of fast operations - these factors very rarely all come together except in kernel world. For pthreads, there are functions pthread_spin_lock_init, pthread_spin_lock, etc. that are entirely analogous to the corresponding functions for mutexes.

"Antoninus Twink" <nospam@nospam.invalid> wrote in message news:slrnfvpt4n.50h.nospam@nospam.invalid... > On 9 Apr 2008 at 13:12, Thad Smith wrote: >> InuY4sha wrote: >>> Can anybody give me the basics (or a *basic* instructions link) >>> regarding spinlocks and their usage? I really can't understand their >>> meaning... >> >> http://en.wikipedia.org/wiki/Spin_lock > > That article seems to focus more on implementing spinlocks than on > using them... > > A spinlock has the same function as a mutex: they're both mutual > exclusion locks. The only difference is the behavior when a thread tries > to gain a lock, but the lock is already held by another thread. If a > mutex is held by another thread, the current thread is suspended and > doesn't resume until it can gain the lock. [...] There are so-called adaptive mutexs that act like spinlocks when contention arises. The difference is that the spin-count is bounded. When the limit is reached, the calling threads becomes a member of the mutexs waitset.

On 10 Apr 2008 at 5:12, Chris Thomasson wrote: > There are so-called adaptive mutexs that act like spinlocks when contention > arises. The difference is that the spin-count is bounded. When the limit is > reached, the calling threads becomes a member of the mutexs waitset. It's a very natural idea - isn't it specific to Solaris though? I can't see that it would be all that difficult to implement efficiently in other threads libraries...

On Apr 9, 5:34 pm, InuY4sha <inuY4...@email.it> wrote: > Can anybody give me the basics (or a *basic* instructions link) > regarding spinlocks and their usage? I really can't understand their > meaning... > Thanks . > R It is also known as busy waiting...

"Antoninus Twink" <nospam@nospam.invalid> wrote in message news:slrnfvshfk.721.nospam@nospam.invalid... > On 10 Apr 2008 at 5:12, Chris Thomasson wrote: >> There are so-called adaptive mutexs that act like spinlocks when >> contention >> arises. The difference is that the spin-count is bounded. When the limit >> is >> reached, the calling threads becomes a member of the mutexs waitset. > > It's a very natural idea - isn't it specific to Solaris though? I can't > see that it would be all that difficult to implement efficiently in > other threads libraries... Its not specific to Solaris.

"Chris Thomasson" <cristom@comcast.net> writes: > "Antoninus Twink" <nospam@nospam.invalid> wrote in message > news:slrnfvshfk.721.nospam@nospam.invalid... >> On 10 Apr 2008 at 5:12, Chris Thomasson wrote: >>> There are so-called adaptive mutexs that act like spinlocks when >>> contention >>> arises. The difference is that the spin-count is bounded. When the >>> limit is >>> reached, the calling threads becomes a member of the mutexs waitset. >> >> It's a very natural idea - isn't it specific to Solaris though? I can't >> see that it would be all that difficult to implement efficiently in >> other threads libraries... > > Its not specific to Solaris. Nor is it specific to C. I suggest taking this to comp.programming.threads. -- Keith Thompson (The_Other_Keith) <kst-u@mib.org> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"