考虑一个场景，其中浏览器有两个或多个指向同一来源的选项卡。不同选项卡的不同事件循环可能导致在访问本地存储时出现竞争条件，并且不同选项卡可能会覆盖彼此在本地存储中的更改。
我正在编写一个将面临此类竞争条件的 Web 应用程序，因此我想了解可在此类场景中使用的不同同步原语。
最佳答案
我对 the relevant W3C spec 的阅读, 和 comment来自 this blog post on the topic 末尾的伊恩·希克森 (Ian Hickson) ，表明应该发生的是浏览器全局互斥锁控制对每个域的 localStorage 的访问。 .每当检查本地存储时，JavaScript 执行的每个单独的“线程”(请参阅下文了解我相当有信心的含义)都必须尝试获取存储互斥锁(如果它还没有)。一旦它获得互斥体，它不会放弃直到它完全完成。
现在，什么是线程，线程完成意味着什么？唯一有意义的事情(也是唯一真正符合 Hixie 的互斥使事情“完全安全”的说法的事情)是 thread 是某些浏览器上下文中的 JavaScript 代码，它是由某些浏览器上下文启动的事件。 (请注意，一个可能的事件是 <script> block 刚刚被加载。)一般浏览器中 JavaScript 的性质是 <script> 中的代码。 block ，或任何类型事件的处理程序中的代码，运行直到它停止；也就是说，运行到 <script> 的末尾正文，否则将运行直到事件处理程序返回。
因此，鉴于此，存储互斥量应该做的是强制所有共享域脚本在尝试声明互斥量时阻止它们中的一个已经拥有它。他们会阻塞直到拥有的线程完成——直到 <script>标记代码用完，或直到事件处理程序返回。该行为将实现规范的保证:
Thus, the length attribute of a Storage object, and the value of the various properties of that object, cannot change while a script is executing, other than in a way that is predictable by the script itself.
但是，基于 WebKit 的浏览器(Chrome 和 Safari，可能还有 Android 浏览器，现在可能还有 Opera？)似乎并不关心互斥锁的实现，这让您陷入了驱使您提问的境地这个问题。如果您担心这种竞争条件(一种完全合理的态度)，那么您可以使用博客文章中建议的锁定机制(由曾经或曾经为 Stackoverflow 工作的人 :) 或实现版本计数系统检测脏写。 (编辑 — 现在我想起来了，RDBMS 风格的版 native 制会有问题，因为仍然会存在检查版本的竞争条件!)
关于html - 在 HTML5 本地存储上实现同步原语，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22274688/