Talk:Non-blocking algorithm

message: It has been suggested by someone else that both "Non-blocking algorithm" and "Lock-free and wait-free algorithms" be merged into this document. That said, I agree that non-blocking algorithm could be merged in/redirected (as algorithms to implement non-blocking sychronization is what is discussed, albeit very briefly, by that article). Similarly, as "Lock-free and wait-free algorithms" are also  examples of non-blocking synchronization algorithms they could also be incorporated - however since the lock-free and wait-free conditions are developed concepts of their own, they probably should only be linked/referenced by this page.—The preceding unsigned comment was added by 216.16.237.2 (talk • contribs) .
:"Non-blocking synchronization" should mean only what it says: that a synchronization primitive does not block. There are many ways to achieve this that do not involve lock-free techniques (another is by using callbacks), and merging the articles would impede fixing the current overemphasis on lock-free techniques in the article. DavidHopwood 21:35, 17 June 2006 (UTC)
thread_title: Merge request

message: Requesting a merge with non-blocking synchronization, due to the fact that:
*non-blocking sync is the more general topic
*obstruction-freedom is also a non-blocking property and isn't covered in this article
*wait-free and lock-free are two different concepts, but both are non-blocking, hence it would makes only sense to a) merge with non-blocking or b)generate two articles one on wait-free algos and one for lock-free (and of course one for obstruction-free algos)
Rattusdatorum 15:00, 16 January 2007 (UTC)
replies: text: In support of the merge, I would add that the Lock-free_and_wait-free_algorithms page is currently a subset of the Non-blocking synchronization page (apart from the links sections, which can be merged). If "non-blocking synchronization" is not the agreed term, the page should be renamed to Non-blocking algorithm, or simply Non-blocking (progress guarantee), but the merge should still be performed. --Chris Purcell 16:29, 16 January 2007 (UTC)
thread_title: Merge request reopened

message: Someone quoth: "Unfortunately, even with special atomic primitives, some common data structures -- such as doubly-linked lists -- have no known lock-free implementation."
Herb Sutter is phrasing things badly. All algorithms have a lock-free implementation, proven decades ago using universal constructions. More recently, software transactional memory has provided reasonably efficient implementations, too. What he must presumably mean is "no direct implementation exists".  —Chris Purcell , 13:08, 21 December 2008 (UTC)
thread_title:  "No lock-free implementation" 

message: The article says that Dekker's algorithm is lock-free. I think this statement is very vague, and, depending on the meaning, incorrect. Dekker's algorithm is a method for implementing critical sections. A program that uses it is, by definition, not lock-free (the program uses critical sections => a thread that crashes in the critical section will bring the whole system to a halt). If you agree, I would remove the mention of Dekker's algorithm. --Gigiultraplus (talk) 21:58, 11 April 2010 (UTC)
thread_title:  Dekker's algorithm is lock free? 

message: Is FastFlow a programming paradigm or an operation that can be implemented in lock-free fashion?  —Preceding unsigned comment added by 75.85.180.100 (talk) 08:36, 1 August 2010 (UTC)
thread_title:  FastFlow 

message: Move Parsecboy (talk) 14:45, 25 August 2010 (UTC)
thread_title:  Requested move 

message: What does 'weak' mean here" "some data structures are weak enough to be implemented". It's use needs to be defined for the non-expert. -- Dougher (talk) 01:05, 5 May 2012 (UTC)
thread_title:  What does 'weak' mean here 

message: 1) Article "Simple, Fast, and Practical Non-Blocking and Blocking Concurrent Queue Algorithms" by Maged M. Michael and Michael L. Scott
3) Survey "Some Notes on Lock-Free and Wait-Free Algorithms" by Ross Bencina
4)  – supports lock-free and thread-safe programming on single variables
5) System.Threading.Interlocked - Provides atomic operations for variables that are shared by multiple threads (.NET Framework)
6) The Jail-Ust Container Library
7) Practical lock-free data structures
8) Thesis "Efficient and Practical Non-Blocking Data Structures" (1414 KB) by Per Håkan Sundell
9) WARPing - Wait-free techniques for Real-time Processing
10) Non-blocking Synchronization: Algorithms and Performance Evaluation. (1926 KB) by Yi Zhang
11) "Design and verification of lock-free parallel algorithms" by Hui Gao
12) "Asynchronous Data Sharing in Multiprocessor Real-Time Systems Using Process Consensus" by Jing Chen and Alan Burns
13) Atomic Ptr Plus Project - collection of various lock-free synchronization primitives
14) AppCore: A Portable High-Performance Thread Synchronization Library - An Effective Marriage between Lock-Free and Lock-Based Algorithms
15) WaitFreeSynchronization and LockFreeSynchronization at the Portland Pattern Repository
16) Multiplatform library with atomic operations
17) A simple C++ lock-free LIFO implementation
18) libcds - C++ library of lock-free containers and safe memory reclamation schema
19) Concurrency Kit - A C library for non-blocking system design and implementation
moved from the article page. it has been tagged as a link farm for over 6 months. per WP:EL each link needs to be individually justified as appropriate. (I have removed some that clearly fail WP:ELNO.)
Which of the above meet the external link criteria and should be returned, and why? -- TRPoD aka The Red Pen of Doom 20:21, 28 October 2012 (UTC)
replies: text: I vote none of them. Also, many of the internal "See also" links appear extraneous to me. --Chris Purcell (talk) 10:30, 5 November 2012 (UTC)
thread_title:  external links 

message: "With few exceptions, non-blocking algorithms use atomic read-modify-write primitives that the hardware must provide"
How do atomic operations not block all other cores from the same resource?
: Dear reader,
: Non-blocking algorithms are "non-blocking" in the same way a normal "read" instruction is considered "non-blocking".
: In a multiprocessor system, often two CPUs simultaneously try to read data from different locations in the same RAM chip.
: Since a typical RAM chip only has one set of address pins, it can only retrieve data from one location at a time.
: In order for the system to work as expected, a properly constructed memory arbiter must somehow choose one of the CPUs to drive the address pins of that RAM chip, and somehow delay the other CPU and keep its desired address disconnected from the address pins of the RAM until the next memory cycle.
: The read instruction running on the delayed CPU always appears to the software to have completed successfully.
: Atomic instructions work the same way, except that a properly designed arbiter sometimes needs to delay the other CPUs several memory cycles in order for multi-memory-cycle atomic instructions to complete and actually appear atomic to those other CPUs -- but those delayed CPUs will resume and finish whatever instruction they are working on within "several memory cycles".
: (By "properly designed", I'm excluding bugs like the Cyrix coma bug).
: In this context, delaying a CPU such that it takes a little longer to execute an instruction, but that instruction always completes successfully within "several memory cycles", is not considered a "block".
: In this context, a "block" is when some other CPU does something that could keep this CPU from doing anything useful for an unlimited amount of time, perhaps more than a hundred memory cycles.
: How can we clarify this article to make this easier to understand? Does it need a distinction between "short delay" and "indefinite block"? --DavidCary (talk) 18:42, 11 March 2014 (UTC)
thread_title:  Realy non-blocking? 

message: Someone once wrote, in a magazine that appears to be a reliable source, several articles criticizing lock-free code for giving "a false sense of security".
My understanding of Wikipedia's WP:YESPOV policy is that each Wikipedia article should mention all of the significant views that have been published by reliable sources on a topic, even the ones I don't agree with.
In an attempt to follow policy,
I added a single sentence with a very brief and watered-down mention of that criticism,
using articles in that magazine as a reference.
(I used WP:BUNDLING to cram several articles into a single reference -- not sure if that was appropriate or not).
When that sentence (and the reference) was deleted, I more-or-less reverted, and the sentence (and the reference) was deleted again.
Rather than deleting statements about the topic that people sincerely believe but are non-neutral (or even wrong), I feel it improves a Wikipedia article on that topic to mention those statements, and then give reliable sources that show that those statements are not facts but merely opinions -- or perhaps even sources that show that experts now consider those statements to be wrong.
This is the "discussion" part of the WP:BRD process.
--DavidCary (talk) 20:04, 11 March 2014 (UTC)
replies: text: Looks good to me. --Chris Purcell (talk) 16:29, 1 July 2014 (UTC)
thread_title:  opinions about non-blocking algorithms 

message: I noticed that the Motivation section is entirely unsourced, and it seems that it uses a much stricter definition of lock-free than the lead paragraph: "A non-blocking algorithm is lock-free if there is guaranteed system-wide progress" only seems to imply a guaranteed absence of deadlock (or livelock), rather than of locks (the synchronization structure). QVVERTYVS (hm?) 20:52, 25 March 2014 (UTC)
thread_title:  Does lock-free really mean "without locks"? 

message: In what way does a single reader/writer lock-free ring buffer without atomic read-modify-write primitives require a size which evenly divides the overflow of an unsigned int as stated in the "Implementation" section?  Take this example of a wait-free implementation that works with any size and without atomic read-modify-write primitives: https://gist.github.com/Izzette/978197feeddf7c82a02457940ba3d6f3.  It is untested but assumed to work (or close to it).
IzzetteIO (talk) 05:43, 26 May 2017 (UTC)
thread_title:  Single reader/writer ring buffer w/o atomic ops has size constraints? 

message: Currently the "persistent memory" article
has a section
Persistent memory#The read-of-non-persistent-write problem
that discusses a "problem ... for lock-free programs".
Is this problem something that also needs to be discussed in this "non-blocking algorithm" article?
--DavidCary (talk) 23:35, 20 September 2021 (UTC)
thread_title:  non-blocking in persistent memory