On Aug 28, 2014, at 6:00 PM, Patrick Walton <pcwal...@mozilla.com> wrote:
> On 8/28/14 5:56 PM, Cameron Zwarich wrote: >> It’s nice that it’s so close to the competition. It would be interesting to >> see numbers on ARM as well, since the relative cost of the atomic >> instructions might be higher, even in the uncontended case. >> >> Is it strictly enforced that the script task never sees inconsistent views >> of layout? This came up in the other thread about threading, but what >> prevents this incorrect scenario? >> >> 1) The script task takes the mutex to access one property of layout. >> 2) The script task releases the mutex. >> 3) Layout changes the property that was accessed. >> 4) The script task takes the mutex again to access the same property, in the >> same turn of the event loop without modifying layout in any intervening work >> since the last attempt. >> 5) The script task reads a different value from before. > > Doh. I wonder if we should just keep the mutex held until the next turn of > the event loop (though don't take it at the outset until the moment script > starts reading back from layout). > > This is actually even better for Clark's benchmark, as it reduces the number > of atomic operations in the tight loop to O(1) from O(n). I assumed that was the case, but was going to wait for his response before the obvious follow-up question. We did a similar thing with iOS WebKit: a recursive mutex that was only released on the turn of an event loop. It was universally regarded as being a terrible idea, but nobody had a better solution. This does mean that we get little-to-no parallelism with things like interactive touch event processing, but that might just be impossible with the web as-is. Cameron _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
