[webkit-dev] Parallel JavaScript: Why a separate ParallelArray types

[Maciej Stachowiak]

On Apr 12, 2013, at 2:13 PM, Filip Pizlo <fpizlo at apple.com> wrote:

> 
> On Apr 12, 2013, at 1:59 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> 
>> On Fri, Apr 12, 2013 at 1:50 PM, Filip Pizlo <fpizlo at apple.com> wrote:
>> 
>> On Apr 12, 2013, at 1:39 PM, Jarred Nicholls <jarred.nicholls at gmail.com> wrote:
>> 
>>> On Fri, Apr 12, 2013 at 2:54 PM, Filip Pizlo <fpizlo at apple.com> wrote:
>>> 
>>> For as little worth as it is, I agree with you Filip that providing low-level primitives would be best in terms of a foundation for many parallel programming models.  In terms of actually supporting shared mutable memory and locks, it would be a challenge for the engines to become thread-safe (internally) across contexts that share memory cells.  I'd envision the sharing of mutable memory being an opt-in semantic, marking a piece of memory as being shared/mutable from multiple contexts.
>> 
>> Fixing the engines is a matter of typing. ;-)
>> 
>> I don't think we need to add language features for opt-in, though this is an intriguing idea.
>> 
>> Without opt-in, the one biggish challenge would be DOM accesses from threads other than the main thread; I suspect for those the initial implementation would have to throw an exception from non-main-threads if you try to access a DOM node.  This is akin to what some UI toolkits do: they let you have threads but prohibit access UI things from anything but the thread on which the runloop sits.  Of course, they don't do the thread-check; we would have to do it to preserve integrity and security.
>> 
>> We already have Web workers for this kind of stuff, no?  Is your proposal significantly different from what Web worker offers?
> 
> Web workers don't have shared memory.  They instead have a really expensive message passing model.
> 
> Yes, my proposal is significantly different from Web workers.

A message passing model a la Web Workers has some advantages compared to threads with shared mutable state and locks:
- No possibility of deadlock
- No possibility of corrupting data structures due to races
- No performance penalty from correctly supporting fine-grained concurrent access to arbitrary mutable objects

The first is particularly important as you really do not want the web page's UI thread to lock up, even if the page itself is not making progress.

I believe message passing as a concurrent programming model is much less prone to severe errors than shared mutable state + locking. I think you have to be super smart to even have a chance of using shared mutable state correctly. That being said, I am not sure Web Workers as they exist today are the best possible form of message passing.

Regards,
Maciej



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130412/b141cdc1/attachment.html>