線形化が必要なのは誰ですか？

レプリケートされたデータベースなどのレプリケートされたシステムの一貫性基準である、直列化可能性と線形化可能性の違いについて読んでいます。ただし、直列化可能性よりも強力な場合でも、どの場合に線形化可能性が必要になるかはわかりません。

このような強力なプロパティが実際に必要になるシナリオを考えていただけますか？

並行、待機フリー（またはロックフリー、より弱い）データ構造の設計を検討してください。このシナリオでは、一般に線形化可能性が必要です。ただし、場合によっては、より弱い正確性条件を満たすことでパフォーマンスとスケーラビリティを改善できます。このような弱い条件を満たす実装が有用かどうかは、通常、アプリケーションに依存します。対照的に、線形化可能な実装はいつでも使用できます。設計者はそれをアトミックとして見ることができるからです。

さらに、線形化可能性は非ブロッキングプロパティです。ブロックするために合計操作（すべてのオブジェクト状態に対して定義）が必要になることはありません。代わりに、Serializabilityは非ブロッキングプロパティではありません。したがって、並行性の程度を高めるために、並行データ構造の設計者は常に線形化可能性に依存しています。

過去15年間に何度もHerlihyとWingを読み直しました。非常に読みにくいです。そして、それは残念です。エッジの周りにいくつかの微妙さがありますが、基本的なアイデアは実際には非常に合理的です。

要するに、線形化は直列化可能性に似ていますが、直列化がトランザクション間の追加の順序制約を尊重するという追加の要件があります。目標は、システム全体について一度に推論するのではなく、個々のアトミックデータ構造について厳密に推論できるようにすることです。

線形化も簡単に実現できます。線形化するオブジェクトにミューテックスを関連付けるだけです。そのオブジェクト上のすべてのトランザクションは、mutexをロックすることで開始し、mutexをロック解除することで終了します。

使用する定義は次のとおりです。

一連のデータに対する一連のトランザクションが与えられた場合、システムは直列化可能です。トランザクションの実行結果は、トランザクションが連続した順序で実行された場合と同じであり、各トランザクション内の操作はその順序でトランザクション内に含まれますトランザクションのコードで指定されます。

直列化可能性は、異なるトランザクション間の操作のインターリーブの出現を許可せず、選択されたトランザクションの順序が因果関係を満たしていることを要求します（トランザクションAが値xを書き込み、トランザクションBがAが書き込んだ値xを読み取る場合、トランザクションAはトランザクションBの前になければなりませんただし、トランザクションの順序に関する他の制約については何も述べていません（特に、プロセスとプロセスがイベントを認識する順序については何も述べていません）。

プロセスが操作を実行する順序に関する制約を追加する別の関連するアイデアがあります（ただし、トランザクションについては個別の読み取り/書き込み操作のみについては説明しません）。

実行結果がすべてのプロセスの操作が何らかの順序で実行された場合と同じである場合、システムは順番に一貫性があり、各プロセスの操作は、プログラムで指定された順序でこの順序で表示されます。（Lamport、「マルチプロセスプログラムを正しく実行するマルチプロセッサコンピュータの作成方法」、IEEE T Comp 28：9（690-691）、1979）。

順次一貫性の定義で暗黙的であるのは、各メモリロケーション（オブジェクト）に対して、ロケーションへの各読み取り操作によって返される値が、書き込まれた値と同じでなければならないというルールに従う操作の誘導された順次順序に従う順序のみを受け入れることですロケーションへの直前の書き込み操作が順番に行われます。xx

線形化可能性には、（a）トランザクションの概念（シリアル化から）とプロセスが発行する操作が順番に完了することを期待するという概念（シーケンシャル一貫性から）を組み合わせ、（b）それぞれについて話すための正確性基準を狭めるという良い意図がありますシステム全体について推論するように強制するのではなく、オブジェクトを分離します。（線形化できない他のオブジェクトがあるシステムでも、私のオブジェクトの実装は正しいと言えると思います。）HerlihyとWingはモニターを厳密に定義しようとしているのではないかと思います。

パート（a）は「簡単」です。順次一貫性のような要件は、各プロセスによって発行されたオブジェクトのトランザクションが、プログラムで指定された順序で結果のシーケンスに現れることです。シリアル化のような要件は、オブジェクトのトランザクションがすべて相互に排他的であることです（シリアル化可能）。

複雑さは、目的（b）（他のすべてのオブジェクトとは無関係に各オブジェクトについて話すことができる）から生じます。

複数のオブジェクトを持つシステムでは、オブジェクトBに対する操作が、オブジェクトAに対して操作が呼び出されたと思われる順序に制約を課す可能性があります。システム全体の履歴を見ると、特定の順序に制限されます。他の人を拒否する必要があります。ただし、単独で使用できる正確性基準が必要でした（グローバルシステム履歴にアピールせずにオブジェクトAに何が起こるかについて推論します）。

たとえば、キュ​​ーであるオブジェクトAの正確性について議論しようとしていると仮定し、オブジェクトBがメモリの場所であり、次の実行履歴があると仮定します。スレッド1：A.enqueue（x）、A dequeue（）（yを返します）。スレッド2：A.enqueue（y）、A.dequeue（）（xを返します）。このキューの実装が正しいことを可能にするイベントのインターリーブはありますか？はい：

Thread 1                           Thread 2
A.enqueue(x)                       ...
...                                A.enqueue(y)
...                                A.dequeue() (returns x)
A.dequeue(y) (returns y)           ...

ただし、履歴（オブジェクトBを含む）が次の場合はどうなりますか？Bは値0で始まります。スレッド1：A.enqueue（x）、A.dequeue（）（yを返す）、B.write（1）。スレッド2：B.read（）（1を返す）A.enqueue（y）、A.dequeue（）（xを返す）。

Thread 1                           Thread 2
A.enqueue(x)                       ...
A.dequeue() (returns y)            ...                       (uh oh!)
B.write(1)                         ...
...                                B.read() (returns 1)
...                                A.enqueue(y)
...                                A.dequeue() (returns x)

「正しい」という定義は、この履歴がAの実装にバグがあるか、Bの実装にバグがあることを示していると言いたいのです。「理にかなっている」シリアル化がないためです（スレッド2まだ書き込まれていないBの値、またはまだキューに入れられていないAの値をスレッド1からデキューする必要があります。）したがって、Aのトランザクションの元のシリアル化は、実装の場合、妥当なもののように見えました2番目のような履歴を許可する場合、それは明らかに正しくありません。

したがって、線形化によって追加される制約は非常に合理的です（FIFOキューなどの単純なデータ構造にも必要です）。たとえば、「実装では、dequeue（）でdequeue（）を許可しないでください。未来。" 線形化可能性は非常に簡単（かつ自然）に実現できます。ミューテックスをオブジェクトに関連付けるだけで、各トランザクションはロックによって開始され、ロック解除によって終了します。単純なミューテックスの代わりにノンブロッキングまたはロックフリーまたはウェイトフリーの手法で原子性を実装しようとすると、線形化可能性に関する推論が難しくなり始めます。

あなたは文献にいくつかのポインタに興味があるなら（私は「リアルタイム」についての議論が必要以上にメイクlinearizabiltyがより困難にすることを赤ニシンの一つだと思いますが。）、私は次のことを見つけます。https：// stackoverflow.com/questions/4179587/difference-between-linearizability-and-serializability

まず、線形化可能性と直列化可能性は直接比較できません。下の表に示すように、主な違いは、左側では、すべての個々の操作がアトミックであるということです（各操作のsynchronized周りにjavaがあるなど。右側では、アトミック性の単位はトランザクションであり、個々の操作はアトミックではありませんシリアル化可能性は常にデータベースに関する文献の一部であり、左側はプロセッサとメモリに関する文献の主題である理由です（読み取り/書き込み操作はアトミック）オリジナルのKey-Valueストア（dbmやmemcached）は左側で開始しました（get / putはアトミックです）が、新しいものはますますトランザクションをサポートしています（Googleのスパナなど）。

obj。操作はアトミックです| トランザクションはアトミックです
-------------------------------- + ----------------- ----------------
線形化可能性|
シーケンシャル整合性| シリアライズ可能性
因果一貫性|
キャッシュの一貫性|

線形化可能性では、並行設定のオブジェクトのシステムは、（a）クライアントが次のように、並列ユニバースで一度に1つの操作（要求/応答のペア）を処理する順次システムと同じ動作をする必要があります。両方の宇宙でまったく同じ応答が見られます（b）時間的順序が保持されます（これについては以下で詳しく説明します）。

Sequential ConsistencyのようなSerializabilityの定義には、最初の基準のみが必要です。

一時的な順序の保存はこれを意味します：A：x.op1（）（Aがクライアント、xがオブジェクト、op1が操作）が別の操作B：y.op2（）が開始する前に終了した場合、シーケンシャルユニバースで要求は同じ順序で処理されます。これはSequential Consistency（SC）では必要ありません。オブジェクトは、クライアントの要求をキューに入れ、クライアントに応答し、後で評価することができます。さらに、オブジェクトは、他のクライアントからの以降の要求を順番に処理し、最初の要求に到達する前にそれを評価する場合があります。

時間的順序の非保存は問題です。A：x.op1（）の後、Aが電話を取り、Bにそれを伝え、Bがx.op2（）呼び出しを呼び出したと仮定します。2番目のステップにはシステムによって追跡されないメッセージが含まれていたため、システムがこの原因となる一連のイベントについて知る方法はありません。多くの実際のケースでは、Aがxが応答した後、Bの呼び出しが更新された状態に依存できると仮定することは不合理ではありません。時間的順序が保存されていない場合、AとBは驚くことになります。これは線形化可能なシステムでは起こりません。

時間的順序保存の2番目の優れた特性は、局所性と合成性です。線形化可能なオブジェクトで構築されたシステム自体が線形化可能です。そのため、1つのモノリシックKey-Valueストアを使用する代わりに、それぞれを独自のKVストアサーバーによって管理される多くの個別のパーティションに分割できます。それぞれが線形化可能な場合、データベース全体が1つの線形化可能なモノリシックKVストアとして機能し、余分な労力は必要ありません。