ONJava.com    
 Published on ONJava.com (http://www.onjava.com/)
 See this if you're having trouble printing code examples


Implementing Mutual Exclusion for AJAX

by Bruce Wallace
04/05/2006

With the increasingly popular AJAX paradigm, a browser page can make requests for server data in the background while the user interface continues to be active in the foreground (hence the "asynchronous" in AJAX). However, the problem exists that these two activities are typically accessing common JavaScript and DOM data structures simultaneously. The classic solutions to this concurrent programming problem are not supplied by JavaScript. This article describes the author's new adaptation of a proven mutual exclusion mechanism that works around the limitations of JavaScript.

Why Mutual Exclusion?

Any time there are multiple threads of program logic that access the same data, and execute at the same time, problems arise. Programs normally assume that the data with which they are interacting is not changing underneath them. The portions of code that access these shared data structures are known as critical sections, and the practice of only letting one run at a time is known as mutual exclusion. This situation arises in AJAX applications when the code, asynchronously handling the reply from an XMLHttpRequest, manipulates data that is also being used by the user interface code. This common data could be JavaScript variables implementing an MVC data model and/or the DOM of the web page itself. The logic of each will break if either is making uncoordinated changes to shared data.

"Wait," you say, "why haven't I run into this problem?" Unfortunately, these kinds of problems are timing dependent (a.k.a. race conditions), so they don't always (or even ever) occur. They are probabilistic based on a number of factors. To be robust, rich internet applications need to prevent this situation by ensuring that these problems can't occur.

So, a mutual exclusion mechanism is needed to ensure that only one critical section will start and finish before another is started. In most mainstream computer languages and execution frameworks, there are (often several) mutual exclusion mechanisms provided, but alas, not in browser-side JavaScript. While there are classic algorithms that implement mutual exclusion without requiring special support from the language or environment, even these expect some basics that are missing from JavaScript and browsers like Internet Explorer. The classic algorithm that follows will then be adapted to work around these browser and language limitations.

The Bakery Algorithm

Of the several mutual exclusion algorithms in the computer science literature, one known as Lamport's bakery algorithm works for multiple competing threads of control when the only communication between them is shared memory (i.e., no special mechanisms like semaphores, atomic set-and-test, etc. are required). The metaphor for this algorithm is a bakery that requires customers to take a number and wait until their number is called. The skeleton of the algorithm (from Wikipedia) is in Listing 1 and it enables each thread to go into and out of critical sections without conflict.

// declaration & initial values of global variables
Enter, Number: array [1..N] of integer = {0};

// logic used by each thread...
// where "(a, b) < (c, d)"
// means "(a < c) or ((a == c) and (b < d))"
Thread(i) {
  while (true) {
    Enter [i] = 1;
    Number[i] = 1 + max(Number[1],...,Number[N]);
    Enter [i] = 0;
    for (j=1; j<=N; ++j) {
      while (Enter[j] != 0) {
        // wait until thread j receives its number
      }
      while ((Number[j]!=0)
         && ((Number[j],j) < (Number[i],i))) {
        // wait until threads with smaller numbers
        // or with the same number, but with higher
        // priority, finish their work
      }
    }
    // critical section...
    Number[i] = 0;
    // non-critical section...
  }
}
Listing 1. Lamport's bakery algorithm pseudocode

As shown, the algorithm assumes that each thread knows its own thread number (constant i) and how many total threads are currently active (constant N). It also assumes that there is a way to wait or sleep; i.e. a way to give up control of the CPU to other threads temporarily. Unfortunately, JavaScript on Internet Explorer doesn't have any of these capabilities. However, the bakery algorithm doesn't break if multiple portions of code running on the same actual thread pretend that each is running on a separate virtual thread. Also, JavaScript does have a mechanism to schedule a function to run after some specified delay, so, the bakery algorithm can be finessed to use these alternatives.

Head Rush Ajax

Related Reading

Head Rush Ajax
By Brett McLaughlin

The Wallace Variation

The major obstacle to implementing Lamport's bakery algorithm in JavaScript is that there is no thread API. There is no way to know on which thread one is running, or how many threads are active; no way to yield the CPU to other threads; and no way to create a new thread to manage other threads. Because of this, one cannot even verify how particular browser events (e.g., button click, XML reply available) are assigned to threads.

An approach that overcomes these obstacles springboards off of the Command design pattern. By putting into a command object all of the logic that should go into a critical section, along with all of the data needed to initiate that logic, the bakery algorithm can be reworked into a class that manages commands. This mutual exclusion class will invoke critical sections (encapsulated as separate command object methods) only when other critical sections are not executing, as if each were in its own virtual thread. JavaScript's setTimeout() mechanism is used to yield the CPU to other waiting commands.

Given a simple base class for command objects (Command in Listing 2), a class can be defined (Mutex in Listing 3) that implements the Wallace variation of the bakery algorithm. Note that, while there are many approaches to implementing class-based objects in JavaScript (and for compactness, a simple approach is used here), any object scheme will work with this technique as long as each command object has some unique id, and entire critical sections are encapsulated in single methods.

 1 function Command() {
 2  if (!Command.NextID) Command.NextID = 0;
 3  this.id = ++Command.NextID;
 4  // unsynchronized API
 5  this.doit = function(){ alert("DOIT called"); }
 6  this.undo = function(){ alert("UNDO called"); }
 7  this.redo = function(){ this.doit();          }
 8  // synchronized API
 9  this.sDoIt = function(){ new Mutex(this,"doit"); }
10  this.sUnDo = function(){ new Mutex(this,"undo"); }
11  this.sReDo = function(){ new Mutex(this,"redo"); }
12 }
Listing 2. Simple base class for Command objects

The Command class happens to demonstrate three critical section methods (lines 5-7), but any method can be used as long as its invocation is wrapped in a Mutex object (as in lines 9-11). It's important to note a key difference between normal method calls (such as invoking the unsynchronized methods) and synchronized method calls: ironically, one must assume that synchronized methods are not run synchronously. In other words, when sDoIt() is called, one must assume that doit() has not run yet, even though sDoIt() has returned. The doit() method may have finished, or it may not even start until some arbitrary time in the future. In still other words, think of a Mutex instantiation as starting a new thread.

 1 function Mutex( cmdObject, methodName ) {
 2   // define static field and method
 3   if (!Mutex.Wait) Mutex.Wait = new Map();
 4   Mutex.SLICE = function( cmdID, startID ) {
 5     Mutex.Wait.get(cmdID).attempt( Mutex.Wait.get(startID) );
 6   }
 7   // define instance method
 8   this.attempt = function( start ) {
 9     for (var j=start; j; j=Mutex.Wait.next(j.c.id)) {
10       if (j.enter
11       || (j.number && (j.number < this.number ||
12                       (j.number == this.number
13                        && j.c.id < this.c.id))))
14        return setTimeout
15  ("Mutex.SLICE("+this.c.id+","+j.c.id+")",10);
16     }
17     //run with exclusive access
18     this.c[ this.methodID ]();
19     //release exclusive access
20     this.number = 0;
21     Mutex.Wait.remove( this.c.id );
22   }
23   // constructor logic
24   this.c        = cmdObject;
25   this.methodID = methodName;
26   //(enter and number are "false" here)
27   Mutex.Wait.add( this.c.id, this );
28   this.enter    = true;
29   this.number   = (new Date()).getTime();
30   this.enter    = false;
31   this.attempt( Mutex.Wait.first() );
32 }
Listing 3. Wallace variation implemented as the class Mutex

The basic logic of the Mutex class is to place each new Mutex instance into a master wait list and start it waiting in line. Each attempt (until the final one) to get to the "head of the line" requires waiting, so setTimeout is used to schedule each new attempt which starts where the current attempt has left off. When the head has been reached (at line 17), exclusive access has been achieved; therefore, the critical section method can be invoked. When the critical section is done, exclusive access is released and the Mutex instance is removed from the wait list (lines 20-21).

The Mutex constructor (lines 23-31) records its Command object and method name parameters and then registers itself into a sparse array of critical sections in progress (Mutex.Wait), which is implemented via the Map class shown in Listing 4. It then gets the "next number" and starts waiting at the end of the line. Since there is not a problem with gaps or duplicates in the wait numbers, the current timestamp is actually used as the "next" number.

The attempt() method combines the two wait loops in the original pseudocode into a single loop that doesn't fall through to the critical section until it is at the head of the line. This loop is a form of busy-wait polling, which can be throttled by the amount of delay specified in the setTimeout() call. Since setTimeout requires a "flat function" to be called, rather than an object method, a static helper method (Mutex.SLICE) is defined in lines 4-6. SLICE locates the specified Mutex object in the master wait list and calls its attempt() method, with the start parameter specifying how far through the wait list it has gotten so far. Each SLICE() call is like getting a "slice of CPU." This cooperative approach of yielding the CPU (via setTimeout) is reminiscent of coroutines.

function Map() {
  this.map  = new Object();
  // Map API
  this.add = function( k,o ){
    this.map[k] = o;
  }
  this.remove = function( k ){
    delete this.map[k];
  }
  this.get = function( k ){
    return k==null ? null : this.map[k];
  }
  this.first = function(){
    return this.get( this.nextKey() );
  }
  this.next = function( k ){
    return this.get( this.nextKey(k) );
  }
  this.nextKey = function( k ){
    for (i in this.map) {
      if ( !k ) return i;
      if (k==i) k=null; /*tricky*/
    }
    return null;
  }
}
Listing 4. Sparse array implemented as a Map data structure

Rich Internet Application Integration

Since Mutex handles a dynamic number of threads (virtual or not), one can get around the fact that an actual thread ID isn't known by acting as if the browser assigns a separate thread to each browser event. A similar simplifying assumption is that each complete event handler constitutes a complete critical section. Given these, each event handler function can be converted into a command object, and Mutex used to invoke and manage them. Of course, if the code is not already cleanly organized into event handling functions then refactoring will be needed. In other words, rather than encoding logic directly in HTML event attributes (e.g., onclick='++var'), define and invoke event handling functions (e.g., onclick='FOO()' and function FOO(){++var;}).

<html>
<script language="JavaScript">
  function newState(){
    if (XMLreq.readyState==4) processReply();
  }
  function requestData(){
      ...set up asynchronous XML request...
      XMLreq.onreadystatechange = newState;
      ...launch XML request...
  }
  function processReply(){
      var transformedData = ...process data to HTML...
      OutputArea.innerHTML = transformedData + "<br>";
  }
  function clearArea(){
      OutputArea.innerHTML = "cleared<br>"; 
  }
</script>
<body onload="requestData();">
 <input type="button" value="clear" onclick="clearArea()">
 <div id="OutputArea"/>
</body>
</html>
Listing 5. Example web page with unsynchronized event handlers

For example, suppose there are three event handler functions that manipulate common data as shown in Listing 5. They handle a page-load event, a button-clicked event and a reply-received-from-XML-request event. The page-load event handler launches some asynchronous request for data. It specifies the request-reply event handler, which processes the received data and loads it into a common data structure. The button-click handler also affects the common data structure. To keep these event handlers from conflicting, they can be converted to commands and invoked via Mutex as shown in Listing 6. (Assume that Map and Mutex are contained in the JavaScript include file mutex.js.) Note that, while elegant class inheritance mechanisms can be used to implement Command subclasses, this code illustrates a minimalist approach, requiring only the global variable NEXT_CMD_ID.

<html>
<script src="mutex.js"></script>
<script language="JavaScript">
  function requestData (){
    new Mutex(new  RequestDataCmd(),"go"); }
  function processReply(){
    new Mutex(new ProcessReplyCmd(),"go"); }
  function clearArea   (){
    new Mutex(new    ClearAreaCmd(),"go"); }
  function newState    (){
    if (XMLreq.readyState==4) processReply(); }

  var NEXT_CMD_ID = 0;

  function RequestDataCmd(){
    this.id = ++NEXT_CMD_ID;
    this.go = function(){
      ...set up asynchronous XML request...
      XMLreq.onreadystatechange = NewState;
      ...launch XML request...
    }
  }
  function ProcessReplyCmd(){
    this.id = ++NEXT_CMD_ID;
    this.go = function(){
      var transformedData = ...process data to HTML...
      OutputArea.innerHTML = transformedData + "<br>";
    }
  }
  function ClearAreaCmd(){
    this.id = ++NEXT_CMD_ID;
    this.go = function(){ 
      OutputArea.innerHTML = "cleared<br>"; }
  }
</script>
<body onload="requestData();">
 <input type="button" value="clear" onclick="clearArea()">
 <div id="OutputArea"/>
</body>
</html>
Listing 6. Web page converted to synchronized event handlers

The three event handler functions have been changed to invoke their original logic (each now wrapped in command classes) via Mutex. Each command class defines a unique ID and a method containing critical section logic, thus fulfilling the command interface requirements.

Conclusion

With AJAX and RIA, the impetus to build complicated dynamic user interfaces is driving developers to use the same design patterns (e.g. Model-View-Controller) formerly tied to "fat" GUI clients. With Views and Controllers being defined modularly, each with their own events and event handlers (but sharing common data models), the potential for conflicts multiply. By encapsulating event handling logic into Command classes, not only can the Wallace variation be employed, but the stage is also set to provide rich undo/redo functionality, scripting interfaces, and unit test instrumentation.

Resources

Bruce Wallace is principal consultant of PolyGlot, Inc.


Return to ONJava.com.

Copyright © 2009 O'Reilly Media, Inc.