Specification: http://dev.w3.org/html5/webstorage/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
Re: Web Storage Editor's Draft 28 November 2011

"The use of the storage mutex to avoid race conditions is currently considered
by certain implementors to be too high a performance burden, to the point
where allowing data corruption is considered preferable. Alternatives that do
not require a user-agent-wide per-origin script lock are eagerly sought
after."

If I understand the issue correctly, NO actual locks are required to ensure
both valid read and write transactions.

There are multiple solutions. An example eventually-consistent solution might
be:

(1) Writes of each process are limited to a store assigned to that process.
(1.a) Those stores do not need to be lock-protected, as there is only one
writer. 
(1.b) However, there may be more than one reader, so the write must be a
complete transaction. That can be accomplished by having a buffered write
queue and a single (in-memory, but ultimately file-backed) value which
represents the index valid buffer. (The size of this value determined by the
size of an atomic write on the architecture e.g. 32 bit atomic integer writes
would be the lowest-common-denominator on common architectures like x86, PPC,
ARM)
(1.c) That index would be continuously incrementing per-session, per-process,
per-write. In theory, the per-session write limits (and buffer counts) are
then unbounded, but the spec does not provide any limits anyway and in
practice, reasonable limits can be made and edge cases (e.g. very long
lasting, partially opened reads from another process) accounted for
separately.
(2) No lock is needed on read, as reads from any process would read through
the integer-ids (incrementing buffer indices) of each other process and use
those to deference last-known-good versions of the value-store. Which are by
(1) guaranteed to not change during the duration of the read (All are
consistent: index, the deferenced value which points to in-memory or
file-store and the final stored value.)

No race conditions, no locks. However, the memory use is higher. But that IS
boundable in practice.

Mike.

Mike Acton <macton@insomniacgames.com>


Posted from: 24.205.74.166
User agent: Mozilla/5.0 (Windows NT 6.0) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.56 Safari/535.11