[whatwg] Application defined "locks"

On Sep 9, 2009, at 6:33 PM, Jeremy Orlow wrote:

> In general this seems like a pretty interesting idea.  It definitely  
> would be nice to completely abstract away all concepts of  
> concurrency from web developers, but some of our solutions thus far  
> (message passing, async interfaces, etc) have not been terribly  
> appreciated by developers either.  The GlobalScript proposal is a  
> good example: to us, shared workers were an adequate solution, but  
> in practice the lack of shared state is very difficult for some  
> developers to work around.  Possibly even more difficult than  
> dealing with some levels of concurrency.
>
> I think it'd be interesting to introduce this as an experimental API  
> and see what web developers do with it.

I think it's predictable that it will be used in badly wrong ways  
without implementing it. Explicit application-managed locking is a  
massive failure as a mechanism for managing concurrency.

> As for the idea of a sync API:  What if some library/framework and  
> the embedding page use these flags/locks?  I know you can't actually  
> deadlock with this API, but I worry some developers will just do | 
> while(!acquireLock("flag")) {}| which could lead to deadlocks.  Only  
> allowing an async API would fix this, but developers have typically  
> not liked async APIs.

If we want to go async, then I'd rather have an asynchronous way to  
acquire an *actual* lock on the resource (as with the LocalStorage  
async transaction proposal), than an async advisory locking model.  
Having both asynchronicity *and* advisory locks seems like the worst  
of both worlds.

On the other hand, if we offer only the equivalent of tryLock() and  
not a blocking lock(), it's almost certain Web apps will build spin  
locks in the way you describe, leading to wasteful CPU usage, bad  
performance, and the possibility of deadlocks.


>
> Here's another idea that I think is actually kind of cool:  What if  
> we kept track of locking precedence (i.e. the graph of which locks  
> have been taken while other locks were held) and threw an exception  
> if any lock was ever taken in a way that violated the graph.  In  
> other words, we wouldn't make the developer tell us the locking  
> precedence, and we wouldn't wait until you hit an actual deadlock.   
> Instead we would look for the first call site that _could_ have  
> deadlocked.  A long time ago, I was working on a project that had  
> some deadlock problems.  We implemented exactly this and it worked  
> pretty well.

This seems like a very challenging programming model for little gain.  
If the locks are purely advisory, they do not prevent race conditions,  
but a discipline to prevent deadlocks will still make them very hard  
to use. Note also that the possibility of synchronous cross-site code  
execution would require a lock precedence graph to be cross-site to  
really prevent deadlocks, but it would be impossible for a Web  
application to guarantee anything about lock order with respect to Web  
apps in different origins. The other possibility is to drop all locks  
in the case of synchronous cross-origin code execution, but then these  
advisory locks would not even be useful for preventing race conditions.

Locking is broken - just don't do it.

Regards,
Maciej


>
>
> On Thu, Sep 10, 2009 at 9:22 AM, Olli Pettay  
> <Olli.Pettay at helsinki.fi> wrote:
> On 9/10/09 2:24 AM, Robert O'Callahan wrote:
> On Thu, Sep 10, 2009 at 6:37 AM, Darin Fisher <darin at chromium.org
> <mailto:darin at chromium.org>> wrote:
>
>    Yes, exactly. Sorry for not making this clear.  I believe implicit
>    locking for LocalStorage (and the implicit unlocking) is going to
>    yield something very confusing and hard to implement well.  The
>    potential for dead locks when you fail to implicitly unlock  
> properly
>    scares me
>
> You mean when the browser implementation has a bug and fails to
> implicitly unlock?
>
> Giving Web authors the crappy race-prone and deadlock-prone locking
> programming model scares *me*. Yes, your acquireLock can't get you  
> into
> a hard deadlock, strictly speaking, but you can still effectively
> deadlock your application by waiting for a lock to become available  
> that
> never can. Also, how many authors will forget to test the result of
> acquireLock (because they're used to other locking APIs that block)  
> and
> find that things are OK in their testing?
> If you're concerned about that, make acquireLock to throw an  
> exception.
> Authors sure will notice that things aren't quite right, if the flag
> isn't acquired.
> And if the acquireLock("flag", callback) approach is used, it is
> harder to make the mistake to not check whether the flag was really  
> got.
>
> This seems like a good idea.
>
> As you said on IRC, perhaps there should be a way to acquire
> many flags at once and then call the callback.
>
> I like this idea as well.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090909/99738a7d/attachment.htm>

Received on Wednesday, 9 September 2009 19:02:22 UTC