?
u
m
/
p
1-9
0
`
メモリ一貫性モデル、すなわち memory model は、SharedArrayBuffer に裏付けられた
メモリーモデルは SharedArrayBuffer 上の
共有メモリアクセス(読み書き)は後述の定義に従い atomic アクセスと data アクセスの 2 群に分けられる。Atomic アクセスは逐次的一貫性を持つ、すなわちエージェントクラスタ内の全エージェントが合意する厳密な全順序が存在する。非 atomic アクセスは全エージェントが合意する厳密な全順序を持たず、すなわち unordered である。
逐次的一貫性より弱く、unordered より強い順序(例: release-acquire)はサポートされない。
Shared Data Block event は ReadSharedMemory、WriteSharedMemory、または ReadModifyWriteSharedMemory
Field Name | Value | Meaning |
---|---|---|
[[Order]] | このイベントに対してメモリーモデルが保証する最弱の順序。 | |
[[NoTear]] | Boolean | このイベントが同一範囲を持つ複数の書き込みイベントから読み取ることを許されるかどうか。 |
[[Block]] | イベントが作用するブロック。 | |
[[ByteIndex]] | 非負 |
[[Block]] 内での読み取りのバイト位置。 |
[[ElementSize]] | 非負 |
読み取りサイズ。 |
Field Name | Value | Meaning |
---|---|---|
[[Order]] | このイベントに対してメモリーモデルが保証する最弱の順序。 | |
[[NoTear]] | Boolean | このイベントが同一範囲を持つ複数の読み取りイベントから読み取られることを許されるかどうか。 |
[[Block]] | イベントが作用するブロック。 | |
[[ByteIndex]] | 非負 |
[[Block]] 内での書き込みのバイト位置。 |
[[ElementSize]] | 非負 |
書き込みサイズ。 |
[[Payload]] | 他のイベントによって読み取られる |
Field Name | Value | Meaning |
---|---|---|
[[Order]] | Read-modify-write イベントは常に逐次的一貫性。 | |
[[NoTear]] | Read-modify-write イベントは tear しない。 | |
[[Block]] | イベントが作用するブロック。 | |
[[ByteIndex]] | 非負 |
[[Block]] 内での read-modify-write のバイト位置。 |
[[ElementSize]] | 非負 |
read-modify-write のサイズ。 |
[[Payload]] | [[ModifyOp]] に渡される |
|
[[ModifyOp]] | 読み取った |
これらのイベントは
一部操作は Synchronize イベントも導入し得る。Synchronize event はフィールドを持たず、他イベントの許容順序を直接制約するためだけに存在する。
ReadSharedMemory / WriteSharedMemory / ReadModifyWriteSharedMemory イベントの範囲はその [[ByteIndex]] から [[ByteIndex]] + [[ElementSize]] - 1 までの連続
考慮すべきpostMessage
など)、エージェントの開始と停止、共有メモリ以外のチャネルによるエージェントクラスタ内通信。特定の実行 execution において、それらイベントは
イベントは以下で定義する関係によって候補実行内で順序付けられる。
Agent Events Record は次のフィールドを持つ
Field Name | Value | Meaning |
---|---|---|
[[AgentSignifier]] | エージェント識別子 | この順序付けに結果した評価を行ったエージェント。 |
[[EventList]] | イベントの |
評価中にイベントがリストへ追加される。 |
[[AgentSynchronizesWith]] | 操作的意味論によって導入された |
Chosen Value Record は次のフィールドを持つ
Field Name | Value | Meaning |
---|---|---|
[[Event]] | この選択値のために導入された |
|
[[ChosenValue]] | 評価中に非決定的に選択されたバイト。 |
candidate execution とは次のフィールドを持つエージェントクラスタ評価の
Field Name | Value | Meaning |
---|---|---|
[[EventsRecords]] | エージェントを評価中に追加されたイベントの |
|
[[ChosenValues]] |
empty candidate execution はフィールドが空
The abstract operation EventSet takes argument execution (a
The abstract operation SharedDataBlockEventSet takes argument execution (a
The abstract operation HostEventSet takes argument execution (a
The abstract operation ComposeWriteEventBytes takes arguments execution (a
read-modify-write 変更 [[ModifyOp]] は
この
The abstract operation ValueOfReadEvent takes arguments execution (a
以下の関係と数学的関数は特定の候補実行をパラメータに取り、そのイベントを順序付ける。
候補実行 execution における is-agent-order-before 関係は次を満たす最小のイベント上の関係である。
各エージェントは評価中にエージェント毎の厳密な全順序でイベントを導入する。これはそれら厳密全順序の合併である。
候補実行 execution における reads-bytes-from 関数は
候補実行は常に reads-bytes-from 関数を許容する。
候補実行 execution における reads-from 関係は次を満たす最小のイベント上の関係である。
候補実行 execution における host-synchronizes-with 関係は
候補実行 execution 内の
この関係はpostMessage
など)を提供させる。
候補実行 execution における synchronizes-with 関係は次を満たす最小のイベント上の関係である。
メモリーモデル文献の慣例により、候補実行 execution では書き込みイベントが読み取りイベントを synchronizes-with する。
候補実行 execution では
候補実行 execution において
候補実行 execution の
候補実行 execution における happens-before 関係は次を満たす最小のイベント上の関係である。
イベント E と D について、次のいずれかが真なら E happens-before D in execution。
happens-before は
候補実行 execution が valid chosen reads を持つとは次のアルゴリズムが
候補実行 execution が coherent reads を持つとは次のアルゴリズムが
候補実行 execution が tear free reads を持つとは次のアルゴリズムが
イベントの [[NoTear]] フィールドは
直感的説明: メモリ範囲が
候補実行 execution において、is-memory-order-before は
R
この節は等しい範囲における
この節とエージェントの前進性保証により、
候補実行は is-memory-order-before 関係を許容するなら sequentially consistent atomics を持つ。
is-memory-order-before は
候補実行 execution が有効実行 (execution) であるとは、以下すべてが真であること。
全てのプログラムは少なくとも 1 つの有効実行を持つ。
実行 execution と
実行 execution と
実行 execution が data race free とは
プログラムが data race free とはそのすべての実行が data race free であること。
メモリーモデルは data race free プログラムの全イベントについて逐次的一貫性を保証する。
以下は共有メモリを扱う ECMAScript プログラマ向けガイドラインである。
プログラムを
より一般には、プログラムが
以下は共有メモリを使用するプログラムにコンパイラ変換を適用する ECMAScript 実装者向けガイドラインである。
単一エージェント環境で有効なほとんどのプログラム変換をマルチエージェント環境でも許容することが望ましい。これによりマルチエージェントプログラムにおける各エージェントの性能が単一エージェント環境と同様に良好となる。しばしばこれら変換は判断が難しい。以下にメモリーモデルによって含意される(またはそれより強い)規範的意図を持つが網羅的ではない規則を示す。これらは
agent-order slice を単一エージェントに関わる
読み取りイベントの possible read values を、そのイベントに対する全有効実行における
共有メモリが存在しない場合に有効なエージェント順スライスの任意の変換は、以下の例外を除き共有メモリ存在下でも有効である。
Atomic は石版に刻まれている: プログラム変換はエージェント順スライス内の
(実際には並べ替え禁止はコンパイラに全
読み取りは安定: 任意の共有メモリ読み取りは 1 回の実行で単一の値のみ観測しなければならない。
(例: プログラム上意味的に 1 回の読みを複数回実行した場合、後続で観測される値はそのうち 1 つのみ許される。Rematerialization として知られる変換はこの規則に違反し得る。)
書き込みは安定: 共有メモリへの全ての観測可能な書き込みは実行中のプログラム意味論から導かれていなければならない。
(例: より大きな場所での read-modify-write を用いて小さなデータを書いたり、プログラムが書き得ない値の書き込み、他エージェントにより上書きされ得る位置に直前に読み取った値をそのまま書き戻したりしてはならない。)
Possible read values は空であってはならない: プログラム変換は共有メモリ読み取りの possible read values を空集合にしてはならない。
(直観に反して、この規則は実際には書き込み上の変換を制約する。書き込みは読み取りイベントにより読まれることでメモリーモデル上の効力を持つため。例えば書き込みは
依然として有効な変換例: 同一位置への複数の非 atomic 読み取りのマージ、非 atomic 読み取りの再順序付け、投機的非 atomic 読み取りの導入、同一位置への複数非 atomic 書き込みのマージ、異なる位置への非 atomic 書き込みの再順序付け、非 atomic 読み取りのループ外へのホイスト(終了性に影響があっても)。一般にエイリアスされた
以下は共有メモリアクセスに対して機械語生成を行う ECMAScript 実装者向けガイドラインである。
ARM や Power より弱くないメモリーモデルを持つアーキテクチャでは、非 atomic store / load は素の store / load 命令にコンパイルできる。Atomic store / load は逐次的一貫性を保証する命令にコンパイルできる。そうした命令が無い場合、フェンス(両側への配置など)を利用する。Read-modify-write 操作は対象アーキテクチャの read-modify-write 命令列(x86 の LOCK
接頭辞、ARM の load-exclusive/store-exclusive、Power の load-link/store-conditional 等)にコンパイルできる。
具体的に、メモリーモデルは以下のコード生成を許容する意図である。
素朴なコード生成パターン:
この写像は、アドレス範囲上の atomic 操作が非 atomic 書き込みまたは異なるサイズの atomic 操作と競合しない限り正しい。それで十分である:メモリーモデルは競合に関与する atomic 操作を非 atomic とみなす。一方素朴な写像は強い:メモリーモデルが実際には保証しない逐次的一貫フェンスとして atomic 操作を使用できる。
これら基本パターンへの局所的改善も、メモリーモデル制約に従う限り許容される。例: