Talk:Spinlock

message: There are many errors in this page:
* The example code:
** the global variable needs a "volatile"
** there is no lock! This code demonstrates polling, not a spinlock.
** The drawn conclusions are wrong.
** The code does not work (or only by pure chance). You cannot do spinlocks in C (or any other higher language)! The update must be atomic, special assembler instructions must be used for this. (otherwise, you get a race condition)
** If you are using pthreads anyway, use pthreads_spinlock, since they have the same effect but are implemented in a useful way (see below; no, they are not really spinlocks).
* Spinlocks are not useful in User-space. 
* In Kernels, they do have an application for SMP-System (on single CPU systems they are never useful). However, the art of kernel design is to avoid spinlock as far as possible (by using per-cpu data, for example). 
* the alternatives for spinlocks are.... strange. Yielding (instead of busy waiting) per cpu/thread data, more complex synchronization mechanisms are better examples.
* the problem of atomic updating of the lock is not touched at all.
* even though many synchronization libraries offer something called spin lock, this is implemented in a different way. One example is the pthread library.
* spinlock are only used if the updating of the data is a bit more complex. A simple increment, decrement, setting, etc. of a single word is done with atomic updates (if available on the particular architecture). 
* the reason to wait for the release of a spinlock is not (or to be more realistic: should never) be to avoid rescheduling, since that would take a long time. Rather, only use spinlock if you are sure that other holders will hold it for a (short) maximum time (rather in terms of nanoseconds than in number of instructions) AND you cannot do rescheduling (in a "normal" way). You also better make sure, that the holder gets not preempted, etc.
* The dangers of spinlocks are not stated (and how to avoid it):
** memory bus usage
** cache trashing
** pipeline bubbles
(plus some more...)
Don't have time right now, will correct it soon, however... --Uvatter 14:02, 17 Dec 2004 (UTC)
thread_title: errors

message: Should create a disambiguation page to a stub for nuclear magnetic resonance spinlock pulse sequence.  —Preceding unsigned comment added by 140.254.233.9 (talk) 15:18, 29 April 2009 (UTC)
thread_title:  Need for disambiguation 

message: A lot of people, textbooks, and several of the papers cited at the bottom of this article use spinlocks and busy waiting interchangeably.  Somebody else set up a redirect for the Busy Waiting page to route here, so that might be where the confusion comes from.
However, it sounds like you're not down with that, and I hate arguing about semantics.  I'll undo the redirect for the busy waiting page, and copy my code there.   I suggest you use this page to talk about the particular OS kernel spinlocks you interested in.  Does that work for you?
--Waxmop 22:29, 29 Dec 2004 (UTC)
thread_title:  Busy waiting page redirects here. 

message: I say no. While spin locks are a form of busy waiting, there are also lots of other ways you can busy wait and spin locks are an important enough concept on their own to merit their own page. --NJM 03:42, 8 November 2005 (UTC)
thread_title:  Merge with busy waiting 

message: The example is here just to give an idea of what a spinlock does and happens to be in x86 asm because that's relatively common. However, the opimizations section goes into great detail with x86 minutiae that isn't really relevant to the article and probably just confuses the issue. I think it should be removed and replaced with a note that the example was written to be easy to understand and isn't the most optimal solution. --NJM 06:44, 28 May 2006 (UTC)
replies: text: I'm not sure.  While some of the details are probably irrelevant, some of them are useful to know about.  It may not be an ideal situation, but most of the world's general-purpose computers are based on the x86 architecture, so optimising things for it is important.  And the information about cache protocols preventing bus traffic is unexpected; I think most people would expect a spinlock to generate a lot of bus traffic and therefore be inefficient because of that, so this is quite important and not x86-specific.  All the information presented may be useful to spinlock implementors, so it should perhaps stay. JulesH 07:57, 26 June 2006 (UTC)
thread_title:  Should the "significant optimizations" section be here? 

message: I've reverted a change from "memory ordering" to "memory operation ordering".
My reason for doing this is that while "memory operation ordering" is a clearer phrase that is likely to be more meaningful to someone not familiar with it, "memory ordering" is the phrase used by most people when discussing it (see, e.g., Intel's description of memory ordering on the Itanium ). JulesH 13:52, 17 July 2006 (UTC)
thread_title:  "Memory ordering" vs "Memory operation ordering" 

message: I've added this sentence:
:But note that such an implementation may require more memory than a spinlock, be slower to allow progress after unlocking, and may not be implementable in a high-level language if out-of-order execution is in use.
While I'm confident that it's true, I could do with a source that confirms it.  My primary reference for such things describes the algorithm, but fails to mention its lack of efficiency or any possible out-of-order problems.  The closest it comes is describing the use of an atomic operation as "simpler".  Any suggestions? JulesH 13:45, 5 October 2006 (UTC)
thread_title:  Source required 

message: * Deadlock/Livelock. In a real-time OS that obeys thread priorities, spinlocks can lead to deadlocks if used by threads with different priorities. The workaround is to never access spin-locks from threads of different priorities. Example: low-prio thread locks spin lock. High prio thread then tries to lock the spin lock. Deadlock, because the high-prio thread is spinning on the lock, and never allows the low-prio thread to unlock.
** I guess this is part of the motivation for so-called "hybrid" spinlocks as used by solaris: if you don't spin unless you know the process that owns the lock is scheduled to another processor, this situation can never arise.  It's an interesting point, and I can certainly see it would be useful to discuss it.  Do you know of any books and/or papers that discuss the issue, that we can use as a reference? JulesH 21:25, 12 June 2007 (UTC)
replies: text:  While that is one workaround, there are several other ways to avoid that kind of deadlock -- any of the solutions to priority inversion would also work. --DavidCary (talk) 17:46, 21 March 2022 (UTC)
thread_title:  New section needed on "the dangers of spinlocks" as Uvatter mentioned above 

message: The article says
:On later implementations of the x86 architecture, spin_unlock can safely use an unlocked MOV instead of the locked XCHG, which is much faster.
While it's much faster for the cpu that does the unlock, it can be actually slower overall, because the write to the spinlock to unlock it will tend to stay in the CPU's store buffer instead of going directly to memory/cache, meaning that other CPUs will see the update later, and will spin for a longer period of time.
For this reason, I don't think this qualifies as a "significant optimization". —The preceding unsigned comment was added by 67.188.127.3 (talk) 09:01, 22 December 2006 (UTC)
replies: text: I believe MESI or other cache coherency systems would take care of this issue in most architectures.  Unless somebody knows otherwise? JulesH 21:29, 12 June 2007 (UTC)

text: In fact, reading the description of MESI linked above, it definitely prevents the issue.  When it modifies the item, it is stored into the CPU's cache and other processors' copies are invalidated.  When they next read the item, they read it directly out of the modifying processor's cache, not out of main memory.  JulesH 21:33, 12 June 2007 (UTC)

text: Sadly, "lock mov" is an illegal instruction.  The lock prefix only applies to a dozen or so instructions: see the list.  "lock sub [locked],1" would work, but would be less clear.Olawlor (talk) 05:04, 3 October 2012 (UTC)
thread_title:  Getting read of atomic operation in unlock is not necessarily a "significant optimization" 

message: it could be good adding some informations about PAUSE instruction and its effects on p4 , xeon and other intel processors...or only a little notify that link on a PAUSE_(x86) like wiki page , with the complete description of this instruction.  —Preceding unsigned comment added by 151.16.98.203 (talk) 19:29, 11 August 2009 (UTC)
thread_title:  adding PAUSE informations.. 

message: I read : 
"... a spinlock is a lock where the thread simply waits ... until the lock becomes available. "
So, the first term lock must mean something different than the second one, if not it would mean A waits until A is true. If A waits, it will never change and thus never become true. 
From my bit of understanding, what is called lock in the second place might be a token, a semaphore or just a certain state, while in the first place it is the code or algorithm performing the active waiting. While many terms in IT are overloaden, we should pay some attention to point to their particular meaning, especially if used close by.
Thus, IMHO it should read: 
"... a spinlock is an algorithm implemented in a single thread which simply waits ... until a certain lock becomes available. "
As the same wording is used in the lock article, same applies for that one.
--Ufalke (talk) 16:32, 5 October 2011 (UTC)
replies: text: I think what the first sentence is trying to say is that the lock causes the thread to wait for the lock. So A (the thread) waits until B (the lock) is true. But I'll try make it more clear. Jfmantis (talk) 03:12, 14 December 2012 (UTC)
thread_title:  logical error in first sentence 

message: After a quick googling, it doesn't seem that "sleeplock" has much traction.  So I remove it while introducing the notion of "raw lock".
ale (talk) 11:09, 15 May 2013 (UTC)
thread_title:  sleeplock vs raw lock 

message: Hello fellow Wikipedians,
I have just modified one external link on Spinlock. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20041211235628/http://www.codeproject.com/threads/spinlocks.asp to http://codeproject.com/threads/spinlocks.asp
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 12:35, 9 December 2017 (UTC)
thread_title:  External links modified