The Brave New World of HTML5
[Home of the HTML5 Car]

There is a trend of installing multiprocessors in computers and mobile devices. Following this trend it is reasonable to provide a means to use multiprocessing capabilities in Web applications. Especially games would be on target. I wondered about a plausible, simple example of Web Workers for teaching purposes.

Usually as introduction to Web Workers you find some code like this:
worker = new Worker("worker.js");
worker.postMessage("Hallo World");
worker.onmessage = function(e){
   alert("Worker said: "+e.data);
}
The code of the worker:
self.onmessage = function(e){
   self.postMessage("I heard "+e.data)
};

I thought that a simulation with Web Workers representing the objects of the simulation might be a good example. In order to keep things simple the following setting was used:

• a user specified number of circles populate a rectangle.
• the circles attract/repel each other with a user specified force
• collisions between circles or with the border of the rectangle result in reflections

What you see below is a serial implementation not using Web Workers but equivalent algorithms for the computations. I put an implementation using Web Workers on the Mozilla Developer Network.

Here some suggested values to play with:
Min radius: 5, Max radius: 10, Number of Balls: 150; Gravitation: 10.
Min radius: 60, Max radius: 80, Number of Balls: 5; Gravitation: -2.

The Web Workers implementation is as follows:

1. create an array of circle objects
2. each circle starts its Web Worker on creation
3. Forever:
   1. every 0.001sec tell all Web Workers to compute next position of their circle
   2. every 0.04sec draw a new frame on the canvas

On this level of detail the serial implementaion doesn’t differ so much:

1. create an array of circle objects
2. Forever:
   1. every 0.001sec loop through all circles:
      1. compute next position of the circle
   2. every 0.04sec draw a new frame on the canvas

What I obviously overlooked with respect to Web Workers: for every computation of a new position the Web Workers needs to know about the speed and position (and mass and radius which can be transmitted during initialization) of all other circles. In languages like Java or Python this is not a problem. These languages provide a shared memory and lock/synch mechanisms for threads. For HTML5/Javascript the only chance to let one circle’s worker know of the position of all other circles is to send the information via postMessage(...). This causes considerable overhead. For each round of computations (every 0.001sec in our model) and for each circle/Worker, all positions and speeds have to be copied and sent via postMessage(...).
For 100 circles this would mean copying 100*100*1,000 = 10,000,000 speed/position informations per second.

Admitted my approach was stupid in several respects:

1. I had not analyzed my requirements properly
2. I relied on Web Workers to provide a similar model as e.g. Python or Java multi-threading (I’d better read the spec!)

In addition I had not read this thread of the WHATWG mailing list which addresses my problem in full detail.
Conclusion: Web Workers – as specified and implemented today – are not suited for multi-threading of applications that require the threads to share a considerable amount of data.