LanguagesJavaScriptAJAX from Scratch: Implementing Mutual Exclusion in JavaScript

AJAX from Scratch: Implementing Mutual Exclusion in JavaScript content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

This AJAX from Scratch series of articles describes fundamental techniques needed to develop AJAX Rich Internet Applications in JavaScript from scratch. Each article focuses on a particular (usually little-covered) aspect of developing browser-side functionality without the use of commercial or server-based frameworks. The techniques described are additionally illustrated in Gravy, a small, but real-world, example JavaScript library and application.


Any time there are multiple threads8 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 sections5, and the practice of letting only one run at a time is known as mutual exclusion4. This situation arises in AJAX applications when the code, asynchronously handling the reply from an XMLHttpRequest17, manipulates data that is also being used by the user interface code. This common data could be JavaScript variables implementing an MVC15 data model and/or the DOM16 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 (also known as race conditions7), so they don’t always (or even ever) occur. They are probabilistic based on a number of factors. To be robust, Rich Internet Applications2 need to prevent this situation thus insuring 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. Although 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 such as Internet Explorer. The classic algorithm that follows then will 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 algorithm6 works for multiple competing threads of control when the only communication between them is shared memory (in other words, no special mechanisms such as semaphores, atomic set-and-test, and so forth are required). The metaphor for this algorithm is a bakery that requires customers to take a number and wait till their number is called. The skeleton of the algorithm is in Listing 1; it enables each thread to go into and out of critical sections without conflict.

// declaration and initial values of global variables
 0 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))"
 1 Thread(i) {
 2   while (true) {
 3     Enter[i]  = 1;
 4     Number[i] = 1 + max(Number[1], ..., Number[N]);
 5     Enter[i]  = 0;
 6     for (j    = 1; j <= N; j++) {
 7       while (Enter[j] != 0) {
 8         // wait until thread j receives its number
 9       }
10       while ((Number[j] != 0) && ((Number[j], j)
                 < (Number[i], i))) {
11         // wait until threads with smaller numbers or with the same
12         // number, but with higher priority, finish their work
13       }
14     }
15     // critical section...
16     Number[i] = 0;
17     // non-critical section...
18   }
19 }

Listing 1. Lamport’s Bakery Algorithm pseudocode (from Wikipedia)

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”; in other words, 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.

The Wallace Variation

The major obstacle to implementing Lamport’s Bakery algorithm in JavaScript is that there is no Thread API. So, 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 (for example, button-click, XML-reply-available) are assigned to threads.

An approach that overcomes these obstacles springboards off the Command design pattern9. By putting all the logic that should go into a critical section into a command object, along with all 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) to implement the Wallace variation of the Bakery algorithm. Note that, while there are many approaches to implement 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 number, and entire critical sections are encapsulated in single methods.

 1 function Command() {
 2   if (!Command.NextID) Command.NextID = 0; //define class variable
 3 = ++Command.NextID;              //define instance variable
 4   // unsynchronized API
 5   this.doit = function(){ alert("DOIT called"); /*override me*/ }
 6   this.undo = function(){ alert("UNDO called"); /*override me*/ }
 7   this.redo = function(){ this.doit();          /*override me*/ }
 8   // synchronized API
 9   this.syncDoIt = function(){ new Mutex(this,"doit"); }
10   this.syncUnDo = function(){ new Mutex(this,"undo"); }
11   this.syncReDo = 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 be can used as long as its invocation is wrapped in a Mutex object (as in lines 9-11).

Note: A key difference between normal method calls (such as invoking the methods defined in lines 5-7) and “synchronized” method calls is that, ironically, one must assume that synchronized methods are NOT run synchronously. In other words, when syncDoIt() is called, one must assume that doit() has not run yet, even though syncDoIt() 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 variable 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; {
10       if (j.enter || (j.number && (j.number < this.number ||
11            (j.number == this.number && < ) ) )
12        return setTimeout("Mutex.SLICE("","")",10);
13     }
14     this.c[ this.methodID ]();    //run with exclusive access
15     this.number = 0;              //release exclusive access
16     Mutex.Wait.remove( );
17   }
18   // constructor logic
19   this.c        = cmdObject;
20   this.methodID = methodName;
21   Mutex.Wait.add(, this );    //enter and number are
22   this.enter    = true;
23   this.number   = (new Date()).getTime();
24   this.enter    = false;
25   this.attempt( Mutex.Wait.first() );
26 }

Listing 3. The 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 that starts where the current attempt has left off. When the head has been reached (at line 14), 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 15-16).

The Mutex constructor (lines 19-25) records its Command object and method name parameters and then registers itself into a sparse array of critical-sections-in-progress (Mutex.Wait) that 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. Because 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 thru to the critical section until it is at the head of the line. This loop is a form of busy-wait polling11 that can be throttled by the amount of delay specified in the setTimeout() call. Because setTimeout requires a “flat function” rather than an object method to be called, 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 approach13 of yielding the CPU (via setTimeout) is reminiscent of coroutines14.

 1 function Map() {
 2  = new Object();
 3   // Map API
 4   this.add     = function(k,o){[k] = o; }
 5   this.remove  = function( k ){ delete[k]; }
 6   this.get     = function( k ){ return k==null ? null :[k]; }
 7   this.first   = function(   ){ return this.get( this.nextKey( ) ); }
 8    = function( k ){ return this.get( this.nextKey(k) ); }
 9   this.nextKey = function( k ){ for (i in {
10                                   if (!k) return i;
11                                   if (k==i) k=null;    /*tricky*/
12                                 }
13                                 return null;
14                               }
15 }

Listing 4. A sparse array implemented as a Map data structure

Rich Internet Application Integration

Because 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 though 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, refactoring will be needed. In other words, rather than logic being encoded directly in HTML event attributes (for example, onclick='++var'), define and invoke event handling functions (for example, onclick='FOO()' and function FOO(){++var;}).

 1 <html>
 2 <script language="JavaScript">
 3  function requestData(){
 4    ...set up asynchronous XML request...
 5    XMLreq.onreadystatechange = newState;
 6    ...launch XML request...
 7  }
 8  function processReply(){
 9    var transformedData  = ...process received data into HTML...
10    OutputArea.innerHTML = transformedData + "<br>";
11  }
12  function clearArea(){ OutputArea.innerHTML = "cleared<br>"; }
13  function newState (){ if (XMLreq.readyState==4) processReply(); }
14 </script>
15 <body onload="requestData();">
16   <input type="button" value="clear" onclick="clearArea()">
17   <div id="OutputArea"/>
18 </body>
19 </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 that 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 Mutex is contained in the JavaScript include file mutex.js.] Note that, although elegant class inheritance mechanisms can be used to implement Command subclasses, this code illustrates illustrates a minimalist approach, requiring only the global variable NEXT_CMD_ID.

 1 <html>
 2 <script src="mutex.js"></script>
 3 <script language="JavaScript">
 4   function requestData (){ new Mutex(new  RequestDataCmd(),"go"); }
 5   function processReply(){ new Mutex(new ProcessReplyCmd(),"go"); }
 6   function clearArea   (){ new Mutex(new    ClearAreaCmd(),"go"); }
 7   function newState    (){ if (XMLreq.readyState==4) processReply(); }
 8   var NEXT_CMD_ID = 0;
 9   function RequestDataCmd(){ = ++NEXT_CMD_ID;
10     this.go = function(){
11       ...set up asynchronous XML request...
12       XMLreq.onreadystatechange = newState;
13      ...launch XML request...
14    }
15  }
16  function ProcessReplyCmd(){ = ++NEXT_CMD_ID;
17    this.go = function(){
18      var transformedData  = ...process received data into HTML...
19      OutputArea.innerHTML = transformedData + "<br>";
20    }
21  }
22  function ClearAreaCmd(){ = ++NEXT_CMD_ID;
23    this.go = function(){ OutputArea.innerHTML = "cleared<br>"; }
24  }
25 </script>
26 <body onload="requestData();">
27  <input type="button" value="clear" onclick="clearArea()">
28  <div id="OutputArea"/>
29 </body>
30 </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.


With AJAX and RIA, the impetus to build complicated dynamic user interfaces is driving developers to use the same design patterns (for example, 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 explode. By encapsulating event handling logic into Command classes, not only can the Wallace variation be employed, but the stage also is set to provide rich undo/redo functionality, scripting interfaces, and unit test instrumentation.


  • The sample code20 in this article is available for viewing or download. It includes the omitted details such that the Web pages can execute directly in the browser without a server connection.
  • An example JavaScript framework (Gravy19) that uses the techniques in this article is available for viewing or downloading, complete with JsDoc18 documentation. Gravy supports placing all application functionality in the browser in JavaScript. Applications need only access the server for REST-style12 requests for database CRUD10 operations.



About the Author

As principal consultant of PolyGlot, Inc., Bruce Wallace has provided consulting and custom computer software development services around the world. Projects have been completed in Sydney Australia, Perth West Australia, “Silicon Valley,” “Route 128” MA, Austin TX, Atlanta GA, and Charlotte NC. Copyright © 2005-2006, PolyGlot, Inc.

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories