Talk:Software lockout

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Computer science (Rated Start-class, Low-importance)
WikiProject icon This article is within the scope of WikiProject Computer science, a collaborative effort to improve the coverage of Computer science related articles on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Low  This article has been rated as Low-importance on the project's importance scale.


There's several things about this article which strike me as a bit iffy, but I'm not a computer scientist so I don't want to start chopping away.

  1. The references to "idle wait" in kernel-level critical sections. I don't know of any architecture that does this; spinlocks ie. "busy waits" are standard in kernel space.
  2. "Typical values for L/E range from 0.01 to 0.1." The reference for this statement is from 1968! By a conservative estimate, computers have gotten at least a billion times faster since then.
  3. The article treats the hardware itself as being contention-free, suggesting an overly theoretical bias; in practice hardware-level contention has informed the development of Linux and presumably other multi-threaded kernels.
  4. "Software lockout is the major cause of scalability degradation in a multiprocessor system"--if this were true we could just run a distinct kernel image on each processor of a NUMA system, consider the problem solved, and take the rest of the day off to play golf.

-- 23:23, 4 September 2007 (UTC)

Spinlocks are often used in kernel space, but shouldn't be used unless the typical time for the wait is less than, say, the time for a context switch; I think at least some systems have "adaptive" locks that spin for a little while and then block to allow the CPU to go do something else, if it looks as if the lock won't get released for a while. In any case, it's a "busy wait" only in the sense that the CPU is busy spinning its wheels; it's not as if the CPU is doing useful work while spinning. Perhaps it should just refer to "wait times". Guy Harris (talk) 01:47, 5 November 2011 (UTC)


Not sure if it's just the scope / title (as a phenomenon) which overlaps with several topics kernel concurrency, scalability, giant lock (see previous merge request), or just needs checking as it's a bit incoherent and presents outdated data (from the 60s) without context in "Analytical studies", and "Software lockout mitigation" e.g. "Many uniprocessor systems..." . Although the CS is timeless, there's a lack of context/perspective and scope overlap which should be considered, and a merge and/or copyedit done. Widefox; talk 15:08, 28 June 2015 (UTC)