W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2009

[whatwg] localStorage mutex - a solution?

From: Rob Ennals <rob.ennals@gmail.com>
Date: Tue, 24 Nov 2009 16:46:17 -0800
Message-ID: <f3fb55dd0911241646v265b946r1228a38d62f96eb4@mail.gmail.com>
In spec language, I think it should be "MAY" release.

In practice, even if it was MUST release, users could potentially see
different behaviour, due to the different scheduling behaviour of
different thread systems etc. Race conditions are inherently
statistical, depending on what happens to be running at a particular
time, and that can depend on all sorts of different variables outside
ones control. This is one of the things that makes concurrent code

As you say, making it MUST release would be a pain to implement.

I think that "MAY" release still helps a lot more than "nothing". If
we have "nothing" then users don't know whether they can be sure that
a sequence of localStorage operations will be atomic.

E.g., I may want to write:

x = localStorage.bla
localStorage.bla = x+1

localStorage.x = localStorage.x - amount
localStorage.y = localStorage.y + amount

These are useful idioms that are only guaranteed to work if we promise
users that the storage mutex cannot be released part way through the

You do however make a very good point. It is important that we don't
encourage users to write programs that might behave differently on
different implementations, and thus get tripped up when different
implementations happen to schedule things differently. I think that
maybe some kind of warnings mode could help here, where we scream
loudly if the user does two localStorage operations in the same thread
with a potentially mutex-dropping operation in between.


On Tue, Nov 24, 2009 at 4:26 PM, Jonas Sicking <jonas at sicking.cc> wrote:
> On Tue, Nov 24, 2009 at 3:12 PM, Rob Ennals <rob.ennals at gmail.com> wrote:
>> Yes. I think that *any* DOM operation, including getElementById should
>> be allowed to release the storage mutex. If we start specifying
>> particular categories of API that do or do not release the mutex then
>> thing will just get confusing, or we will find that we have missed
>> something important.
> "Allowed to release" or "must release"?
> If it's "allowed to release" then that's not really helping that much
> since in the end different implementations might still do different
> things, causing incompatibilities.
> If "must release" then I have no idea how to implement that. There are
> hundreds of API entry points, and I really don't want to add code to
> release the mutex in each and every one of them. Both for code sanity
> reasons, and for performance reasons.
> / Jonas
Received on Tuesday, 24 November 2009 16:46:17 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:19 UTC