Talk:Linearizability

message: The page currently states:
* In concurrent programming, atomicity is equivalent to linearizability, which has the additional property that none of its effects are visible until after it completes. That is, that there are no intermediate states visible to other threads. (In database systems, this property is classified separately as "isolation".)
* In operating systems, an "atomic" operation is an operation that is not (or cannot be) interrupted once it has begun. For example, basic machine instructions like add or store are usually guaranteed by the hardware to be atomic, and some platforms provide a pair of operations (load-link/store-conditional) that only have an effect if they occur atomically. This property can be used to implement locks, a vital mechanism for multithreaded programming
However, the latter is merely a special case of the former, and hard to define rigorously. "Atomicity = linearizability" makes much more sense even in operating systems. I suggest merging the two, and moving away from "atomicity includes isolation" to "atomicity means the operation appears to take effect instantaneously at some point", in the interest of simplification and clarification. Chris Purcell 09:30, 7 February 2006 (UTC)
thread_title: Atomicity and linearizability

message: I have reverted the edit of Ewlyahoocom as it conflates the database ideas of isolation and atomicity, to the point where the article is now factually inaccurate. Perhaps we could discuss and refine the changes here before pushing them live again? --Chris Purcell 23:44, 10 April 2006 (UTC)
thread_title: Revisions

message: --24.251.211.127 01:34, 28 July 2006 (UTC)
thread_title:  Too abstract 

message: Many of the pages that link to this "linearizability" article
use this pattern: atomic operations.
I find this odd, since there is an atomic operation article, and it doesn't even mention "linearizability" (except as an uncommented bullet point in the final "See also" section).
If "linearizable" and "atomic operation" really mean the same thing (as implied by the current first sentence of the linearizability article, and also implied by the atomicity disambiguation page), shouldn't we merge the two articles?
If they mean different things, shouldn't the "atomic operation" article say a few words about the difference, and shouldn't other articles that are really talking about linearizability use a linearizability link and other articles that are really talking about atomic operations use a atomic operations link?
--68.0.124.33 (talk) 06:31, 3 December 2008 (UTC)
replies: text: I see there is a long discussion at Talk:Read-copy-update of whether or not "atomic = linearizable". Could we summarize the conclusions in this linearizability article and the atomic operation article? --68.0.124.33 (talk) 07:14, 3 December 2008 (UTC)
replies: text:  There are no references in the discussion or in the Read-copy-update article. This discussion appears to be original research and can't be included here. --Kvng (talk) 16:52, 17 September 2010 (UTC)

text: Apparently complex merge issues aside, I'd like to know why this article is called Linearizability and not Atomicity (programming) or somesuch. Comments at the top of this section indicate that Atomicity is the term most often used when linking to this article. I was personally confused when I arrived here from one of these links. Atomicity shows up on Goole 20x more than Linearizability. --Kvng (talk) 16:52, 17 September 2010 (UTC)
replies: text:  (1) The numbers I see are ~240K hits for an "atomicity" search, ~32.7K for "linearizability" (about 7x). However, the overwhelming majority of (at least the first few pages of) the atomicity hits have nothing to do with the subject at hand, while every linearizability one does, so that comparison is meaningless. (2) "Linearizability" is the accepted term in technical literature. --Chris Purcell (talk) 15:49, 18 September 2010 (UTC)
replies: text: Don't know what we're doing differently but I get 747K Google hits for atomicity. I don't know how to fairly assess what all of these hits refer to so instead let me pile on a bit more evidence for good measure. In a Wikipedia search, linearizability shows up 9 times and atomicity shows up 16,134! I don't know if you have a citation to back up your technical literature claim. I've done a couple searches with Google scholar and atomicity (78,200 hits) soundly beats linearizability (11,600 hits) there too. A patent search yields 30 linearizability hits and 408 for atomicity. --Kvng (talk) 18:53, 18 September 2010 (UTC)

text: Atomicity (database systems) is one of the pivotal parts of ACID in databases. Of course there are lots of hits. As for "linearizability", there's the original usage citation on the page, plus the 11 thousand others you mentioned, since to my knowledge the word isn't used for any other purpose. I'm not fundamentally opposed to renaming the page, but in my experience it's "atomic" and "linearizability" in concurrency, not "atomicity", and "number of hits" is not valid evidence to the contrary (for the reasons specified). --Chris Purcell (talk) 19:59, 18 September 2010 (UTC)
replies: text: I would like to submit a WP:RM application and see how that goes. But first I'd like to try and select a new name candidate. Here are the current redirects to this page: Atomic (computer science), Atomic action, Atomic actions, Atomic operation, Atomic operations, Atomic primitive, Atomicity (programming), Indivisibility (programming), Indivisible operation, Strict consistency, Uninterruptibility (programming). Do any of these strike anyone's fancy? Atomic operation is the most popular link target but that's probably because up until July, it was a stand-alone article. I personally prefer Atomicity (programming) or Atomicity (computer science). --Kvng (talk) 21:55, 18 September 2010 (UTC)
replies: text:  Once again, "linearizable" is the accepted term in academic literature, hence I fail to see the need for a page rename. However, "atomic" would be preferable to "atomicity", since I believe the latter is mainly used with reference to ACID (i.e. all-or-nothing operations), not concurrency, and is more easily confused as a result. --Chris Purcell (talk) 16:28, 20 September 2010 (UTC)
replies: text:  I don't mean to try your patience. I understand your assertion for "linearizable" but I haven't seen any backing for it. I admit I'm not coming at this from an academic perspective so you could well be right (though I'd still like to see some evidence). What I'm trying to do is improve terminology consistency within Wikipedia. Arriving at an article called "linearizable" after clicking on an "atomicity" link is a problem in my opinion. Do you understand my assertion? --Kvng (talk) 17:25, 20 September 2010 (UTC)

text:  Obviously your opinion is valid. If you want evidence about "linearisability", read some of the academic articles you found with a simple search, or the Herlihy citation on the page. Other than that, "atomic operation" would be an acceptable name for the page. --Chris Purcell (talk) 07:47, 21 September 2010 (UTC)

text: FWIW. Technically, there is a subtle difference between linearizable and atomic, see . The difference is that linearizability requires atomicity plus preserving order of non-concurrent operations. Therefore, probably current article should be split into two separate articles along this line. For me, it does not look as two different terms for the same entity, as in academic literature both atomic operations and linearization are routinely used in similar, though not identical sense (see for example fundamental works in compare-and-swap field  and ,  often wording goes along the lines of linearizability which implies operations are atomic). Ipsign (talk) 06:15, 4 December 2010 (UTC)
replies: text: Comment: I came here from the link at Wikipedia talk:WikiProject Computing. What's the specific proposal on the table? --Pnm (talk) 01:07, 7 December 2010 (UTC)
replies: text: The proposal prior to Ipsign's contribution was to rename the article Atomic operation --Kvng (talk) 03:13, 7 December 2010 (UTC)

text: I would propose to split the article in two: Linearizability and Atomic operation, and explain the difference between two in Linearizability (which relies on Atomic operation). Ipsign (talk) 15:40, 7 December 2010 (UTC)
replies: text: I support the split. The existing lead seems to more closely summarize atomic operation, so for the mechanics, I suggest first moving this article to become the new Atomic operation, then split back to Linearizability "under" the redirect. I named the subject headings explicitly to prepare for the move. --Pnm (talk) 23:48, 7 December 2010 (UTC)

text: In databases, "atomic" means something different (all-or-nothing). I vote to keep as is. --Chris Purcell (talk) 12:00, 13 March 2015 (UTC)
replies: text:   Are there any articles about the "all-or-nothing" definition, besides this one? This article includes in the opening paragraph: "Additionally, atomic operations commonly have a succeed-or-fail definition."  The "appears visible from other threads" is interesting, but much more subtle.  I would like to see an article that looks at the "all-or-nothing" concept of "atomic," both in databases and in concurrent programming --Yoderj (talk) 15:07, 25 May 2015 (UTC)
thread_title:  linearizability and atomic operation 

message: The term "atomic" more clearly states the conceptually-easiest form of this concept.  Perhaps we should rename the page to Atomic operation? --Yoderj (talk) 17:22, 6 March 2015 (UTC)
replies: text: In databases, "atomic" means something different (all-or-nothing). I vote to keep as is. --Chris Purcell (talk) 12:00, 13 March 2015 (UTC)
replies: text:   Are there any articles about the "all-or-nothing" definition, besides this one? This article includes in the opening paragraph: "Additionally, atomic operations commonly have a succeed-or-fail definition."  The "appears visible from other threads" is interesting, but much more subtle.  I would like to see an article that looks at the "all-or-nothing" concept of "atomic," both in databases and in concurrent programming --Yoderj (talk) 15:07, 25 May 2015 (UTC)
thread_title:  Rename to Atomic? 

message: please comment on phrase "atomicity race"  —Preceding unsigned comment added by Skysong263 (talk • contribs) 18:45, 21 December 2009 (UTC)
thread_title:  Atomicity race 

message: The page says, "the Apache Portable Runtime library provides a selection of atomic operation function macros for use within MPL [Mozilla Public License?] licensed software."  Is this really right?  Apache Foundation software is (almost?) always under Apache License.  And derivative works are not required to use that license. Superm401 - Talk 04:28, 10 January 2009 (UTC)
thread_title: APR

message: The example details a situation, but it doesn't explain what the situation has to do with atomic operations. --Snaxe/fow (talk) 02:10, 10 April 2009 (UTC)
replies: text: Hopefully that's a bit clearer now --Chris Purcell (talk) 11:12, 10 July 2010 (UTC)
thread_title:  The example 

message: I recommend redirecting the atomic action stub to this page. Atomic actions fall under the linearizability umbrella; the stub mainly describes some possible implementation details that may or may not enhance this page. --Chris Purcell (talk) 09:35, 5 August 2010 (UTC)
replies: text: Merge done. --Chris Purcell (talk) 16:28, 28 August 2010 (UTC)
replies: text: But now here is the problem that the link atomic action in the "See also" part is redirected to the article itself. 134.91.76.129 (talk) 12:59, 2 December 2010 (UTC)
replies: text: Removed the see also. --Pnm (talk) 23:31, 3 December 2010 (UTC)
thread_title:  Merge with [[Atomic action]] 

message: What is the section on strict consistency doing here? Could someone expand on the relation of linearizability to strict consistency? Or maybe we can remove this useless section --Jetru (talk) 12:40, 8 April 2011 (UTC)
thread_title: Strict Consistency

message: The section "Primitive atomic instructions" has a statement in it that reads:
"Atomic swap as used in some Burroughs mainframes, also called XCHG."
The XCHG operator is emitted by the compiler to implement its needs in stack manipulation, but is not accessible to the user directly. [It was, in ESPOL, but ESPOL is no longer used.] It causes the two top-of-stack values to be exchanged; that is, it only affects the stack.
The user-accessible instruction that is used for implementing locks is RDLK (ReadLock). It exchanges a top-of-stack value with an address in memory, in one uininterruptible swell foop.
EXCH & RDLK are both atomic, in that they are not interruptible. Other "atomic" operators are RSUP & RSDN, which manipulate the top 3 stack cells. But only RDLK is accessible to programmers (in Algol & NEWP) & thus used with implementing locks.
Thus, I believe the line should read, "Atomic swap as used in some Burroughs mainframes, also called RDLK." Or, it should stated another way, but involve the use of RDLK, not EXCH.  — Preceding unsigned comment added by 70.181.124.207 (talk) 06:54, 28 February 2013 (UTC)
replies: text: . I agree that that line incorrectly implies that XCHG was used by programmers of Burroughs mainframes. --DavidCary (talk) 18:03, 4 June 2014 (UTC)
thread_title:  "Primitive atomic instructions" as relates to Burroughs mainframes 

message: I propose that Immediate consistency be merged into Linearizability (or, alternatively, Immediate consistency should be deleted). These are the same models, and the former is non-standard terminology for the latter. Pbailis (talk) 23:49, 18 June 2013 (UTC)
replies: text: I second deletion. --Chris Purcell (talk) 23:19, 17 July 2013 (UTC)
thread_title:  Merger proposal 

message: Linearizability should be a separate article from atomicity. The current definition of atomicity is simply wrong. I won't comment on the definition of linearizability because I can't follow it, but it should probably be defined in terms of total orders.
Here's what I propose for atomicity:
In computer science, an operation (say, X) is atomic with respect to some other operation (say, Y), if it appears to Y that X either occurs all at once, or not at all.
Atomicity allows the correctness of Y to depend on a property being true, even though the property may not be true during the execution of X, because Y cannot observe the period during which X is executing.
If X is atomic with respect to Y, then it is sufficient (for the correctness of Y) for the property to be true before and after X executes.
Note that an operation may be atomic with respect to some operations, and not atomic with respect to others. 
Note also that atomicity is not necessarily symmetric: X may be atomic with respect to Y, without Y being atomic with respect to X.
Atomicity is similar to mutual exclusion--mutual exclusion prevents the occurrences of X and Y from overlapping--but the two concepts are not identical.
Atomicity may be implemented by mutual exclusion, or by other methods such as optimistic concurrency control.
Mutual exclusion is often implemented by using atomicity, but does not require it. A New Solution of Dijkstra's Concurrent Programming Problem, Communications of the ACM, Vol. 17, Num. 8 (August 1974), pp. 453-455.
=== References ===
Tim Leonard (talk) 19:05, 29 June 2015 (UTC)
thread_title:  Separate atomicity from linearizability 

message: Tim Leonard (talk) 19:05, 29 June 2015 (UTC)
thread_title:  References 

message: Mainly the definition stated on the page is invalid. 
In the second, it mixes formal and informal styles very badly. Not only in the intro part, but in the definition itself.
> If an operation op1 completes (gets a response) before op2 begins (invokes), then op1 precedes op2 in σ.
This is not part of the definition. And its states mainly nothing if understood right. It's formulated very unclearly.
> if a response preceded an invocation in the original history, it must still precede it in the sequential reordering.
It may be thought that its states about the order in σ, but it's still not very clear. Both conditions, the original one, and reformulated one hardly reflects what it states about. What is sufficient and what is necessary. Also it states its from [2], but anyway the def in [2] is different.
> For every completed operation in σ, the operation returns the same result in the execution as the operation would return if every operation was completed one by one in order σ.
Its partly formal, and mainly rewritten in that form for some unknown purpose. The original def is much clearer.
There are also examples there which maybe separated into independent section.
I offer:
# Take exact definition from one of the works of Herlihy, Maurice P.
# Take both informal and formal definitions from that work - they are good and clear.
# Add examples from Linearizability: A Correctness Condition for Concurrent Objects
John.koepi (talk) 21:21, 1 July 2017 (UTC)
thread_title:  Proposal to rewrite _Definition of linearizability_ section 

message: DB and DC have some of the same words that mean vastly different things. "Atomic" is a simple example. Mixing serializability with linearizability is problematic because the former is a DB term and the latter from DC. The operating models aren't compatible. DB talks about transactions made up of multiple operations, where DC is focused on a single operation and what happens in the presence of other operations. http://www.bailis.org/blog/linearizability-versus-serializability/ has a really great breakdown of the problem.
Bcr33d (talk) 15:34, 23 September 2019 (UTC)
thread_title:  Improper mixing of database terminology with distributed computing 

message: I don't understand why the "Atomic" implementation of the Counter is linearizable. I understand that the individual read/write operations are linearizable (because each register is only written by a single process). The "increment" operation has a linearization point at step 3 (write to Ri), but it doesn't seem like the Read operation needs to have a linearization point. Specifically, consider the following execution with 3 processes, starting at time 0 (with all registers initialized to 0):
- Process 1 increments at times 1 and 2 (i.e., these are the linearization points)
- Process 2 increments at time 3
- Process 3 calls increment at time 1: it reads 1 from R1 a time 1.5 and reads 1 from R2 at time 3.5. Thus, it returns a value of 2.
It doesn't seem this execution can be linearized because there is no time at which R1 has value 1 and R2 has value 1. Such a linearization point would have to be after 1 and before 2 (because process 3 read 1 from R1), but after time 3 (because process 3 read 1 from R2). 
Am I missing something here?
Will.rosenbaum (talk) 16:55, 23 March 2021 (UTC)
thread_title:  A problem with the "Counter" example?