[2] ストレージミューテックスstorage mutexは、 Webブラウザーが Cookie の書き込み等の競合状態の回避のために使うミューテックスでした。

[42] 仕様上の概念としては存在していましたが、技術的問題から現実には実装されていませんでした。 競合状態を正しく処理する実装方法を用意するために仕様上は残されていましたが、 今後実装される見込みもないため、2015年末に削除されました。

仕様書

処理モデル

[3] 利用者エージェントは、ストレージ・ミューテックスを1つ持って構いません。 ストレージ・ミューテックスは、ある時点で

... のいずれかの状態にあります。 >>1

イベントループによる所有

[10] ストレージ・ミューテックスを得るstorage mutex場合は次のように処理しなければなりません >>11。

  1. [12] 当該タスクのイベント・ループが既にストレージ・ミューテックスを所有しているなら、 これらの手順から抜けます。
  2. [13] そうでなければ、イベント・ループがストレージ・ミューテックスを取得できるまで一時停止します。
  3. [14] ストレージ・ミューテックスの所有権を取得します。

イベントループがストレージミューテックスを得る状況

[15] ストレージミューテックスの取得は次の状況で行われます。

  • [16] document.cookie の読み書き
  • [17] http-equiv が Set-Cookie である meta 要素の処理
  • [18] localStorage の読み書き

[19] sessionStorage の読み書きにはストレージミューテックスは関与しません。[48] その他利用者エージェント依存のタイミングでクッキーを削除する場合 (クッキー参照。) にも取得する必要がありそうです (イベントループ上の処理かどうかはわかりませんが...)。

fetch 算法による所有

[20] ストレージ・ミューテックスは、 fetch 算法の中で Set-Cookie: の処理のために所有され、処理が終わり次第解放されます。

解放

[5] 利用者エージェントは次の場合にストレージミューテックスを解放releaseしなければなりません。

  • [6] スクリプトがプラグインを呼び出した時 >>1
  • [7] プラグインがスクリプトを呼び出した時 >>1
  • [21] fetch 内での処理が終わった時 (>>20)
  • [22] window.open 算法の途中
  • [23] document.domain で新しい値が設定される時
  • [24] navigate 算法の途中
  • [25] prompt to unload a document 算法の途中
  • [26] unload a document 算法の途中
  • [27] イベント・ループでタスクを処理した直後
  • [49] マイクロタスクを処理した直後
  • [28] alert, confirm, prompt の途中
  • [29] printing steps 算法の途中
  • [30] showModalDialog 算法の途中
  • [31] navigator.yieldForStorageUpdates
  • [32] run a worker 算法の途中
  • [38] XHR send (同期フラグが設定されている場合) >>37

navigator.yieldForStorageUpdates

[35] navigator.yieldForStorageUpdates (NavigatorStorageUtils インターフェイスの yieldForStorageUpdates メソッド) が呼び出されると、 利用者エージェントは、そのメソッド呼び出しを行ったタスクのイベント・ループがストレージ・ミューテックスを所有しているなら、 これを解放しなければなりません。 >>34

実装しない

[4] 利用者エージェントはストレージ・ミューテックスを実装しないことを選択しても構いません。 その場合、ストレージ・ミューテックスの取得や解放に関する要件は実装しなくて構いません。 >>1

[8] ストレージ・ミューテックスを使わないと、あるサイトが複数の窓から同時に Cookie や Web Storage にアクセスした時にデータが壊れる危険性があります。 しかしストレージ・ミューテックスを使うと、あるサイトが Cookie や Web Storage を使うと他のすべてのサイトがブロックされてしまうことから、 Webブラウザー全体のパフォーマンスに大きく影響します。 Webブラウザーの実装者はこの2つの「evil」のどちらかを選択せざるを得ません。 >>1

[9] これは Web Storage が失敗だったとされる理由の一つです。

[36] Web Storage の仕様上、スクリプトの実行途中に localStorage の値は (そのスクリプト自身が予測できない形で) 変化することはない、とされています。 >>33 しかし >>4 の通りストレージ・ミューテックスを実装しないことを利用者エージェントが選択しているなら、 これは保証されません。

[43] 現実にはすべての Webブラウザーがこの方法を選択しています >>41。 すなわちストレージミューテックスは仕様上にしか存在しません。 通常は実装されない仕様は削除されるものですが、 HTML Standard の編集者である Ian Hickson は、データが破壊される可能性がある実装しか認められないのは好ましくないとして、 ストレージミューテックスの仕様を残しています >>40。

歴史

削除

[50] Remove the storage mutex due to lack of implementation · whatwg/html@1b918cf ( 版) https://github.com/whatwg/html/commit/1b918cf72fcbba011f83b92ab5d1f483fb1cafa3

[51] Remove navigator.yieldForStorageUpdates() due to lack of implementation · whatwg/html@c6fb03d ( 版) https://github.com/whatwg/html/commit/c6fb03dc3d9396f3a3c7f62b1c5cba1ed73cd9c5

[52] Fix #45: remove references to the storage mutex · whatwg/xhr@2529712 ( 版) https://github.com/whatwg/xhr/commit/25297128a14c543c909a052b2933d2b0b72550d1

[53] Fix #198: give precedence to custom Authorization headers · whatwg/fetch@9b18866 ( 版) https://github.com/whatwg/fetch/commit/9b188662ab3d0319fe6e5fc10f034a9f10f7b069