<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 9, 2009, at 6:33 PM, Jeremy Orlow wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>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.</div> <div><br></div><div>I think it'd be interesting to introduce this as an experimental API and see what web developers do with it.</div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div>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.</div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><br><blockquote type="cite"> <div><br></div><div>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.</div></blockquote><div><br></div><div>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.</div><div><br></div><div>Locking is broken - just don't do it.</div><div><br></div><div>Regards,</div><div>Maciej</div><div><br></div><br><blockquote type="cite"> <div><br></div><div><br></div>On Thu, Sep 10, 2009 at 9:22 AM, Olli Pettay <span dir="ltr"><<a href="mailto:Olli.Pettay@helsinki.fi">Olli.Pettay@helsinki.fi</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im">On 9/10/09 2:24 AM, Robert O'Callahan wrote:<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"> On Thu, Sep 10, 2009 at 6:37 AM, Darin Fisher <<a href="mailto:darin@chromium.org" target="_blank">darin@chromium.org</a><br></div><div class="im"> <mailto:<a href="mailto:darin@chromium.org" target="_blank">darin@chromium.org</a>>> wrote:<br> <br> Yes, exactly. Sorry for not making this clear. I believe implicit<br> locking for LocalStorage (and the implicit unlocking) is going to<br> yield something very confusing and hard to implement well. The<br> potential for dead locks when you fail to implicitly unlock properly<br> scares me<br> <br> You mean when the browser implementation has a bug and fails to<br> implicitly unlock?<br> <br> Giving Web authors the crappy race-prone and deadlock-prone locking<br> programming model scares *me*. Yes, your acquireLock can't get you into<br> a hard deadlock, strictly speaking, but you can still effectively<br> deadlock your application by waiting for a lock to become available that<br> never can. Also, how many authors will forget to test the result of<br> acquireLock (because they're used to other locking APIs that block) and<br> find that things are OK in their testing?<br> </div></blockquote> If you're concerned about that, make acquireLock to throw an exception.<br> Authors sure will notice that things aren't quite right, if the flag<br> isn't acquired.<br> And if the acquireLock("flag", callback) approach is used, it is<br> harder to make the mistake to not check whether the flag was really got.<br></blockquote><div><br></div><div>This seems like a good idea. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> As you said on IRC, perhaps there should be a way to acquire<br> many flags at once and then call the callback.<br></blockquote><div><br></div><div>I like this idea as well.</div></div></blockquote></div><br></body></html>