> > > So long as you only allow asynchronous access the implementation can > ensure that a worker and the main thread doesn't have access to the > storage at the same time. Then it is safe to allow everyone to modify > the storage area. > > / Jonas > > This is true, serialising access would have the same semantics as STM. Infact you could consider STM to be a performance enhancement to sequential access by optimistically allowing concurrent modifications and only doing something special if there is a collision (a read from a location written by another thread during the transaction). In which case STM works like a database and rolls back the transaction. It is really putting a thread local "log" between the user and the storage. The main storage is then only locked during the log commit, reducing resource contention. A rollback is simply discarding the log. But this would behave identically (apart from the extra features in STM like guards and retry) to serialisation of requests. A simple (non STM) implementation would be to have a single thread associated with the localStorage and require all accesses to be executed by that thread (in callbacks). You could use the main UI thread, but it would make worker threads wait for storage access during DOM processing in callbacks etc... Cheers, Keean.
Received on Friday, 7 January 2011 11:00:58 UTC