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 this.map = new Object();
3 // Map API
4 this.add = function(k,o){ this.map[k] = o; }
5 this.remove = function( k ){ delete this.map[k]; }
6 this.get = function( k ){ return k==null ? null : this.map[k]; }
7 this.first = function( ){ return this.get( this.nextKey( ) ); }
8 this.next = function( k ){ return this.get( this.nextKey(k) ); }
9 this.nextKey = function( k ){ for (i in this.map) {
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(){ this.id = ++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(){ this.id = ++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(){ this.id = ++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.
Conclusion
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.
Examples
- 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.
References
- http://en.wikipedia.org/wiki/AJAX
- http://en.wikipedia.org/wiki/Rich_Internet_Application
- http://en.wikipedia.org/wiki/Concurrent_programming
- http://en.wikipedia.org/wiki/Mutual_exclusion
- http://en.wikipedia.org/wiki/Critical_section
- http://en.wikipedia.org/wiki/Lamport%27s_bakery_algorithm
- http://en.wikipedia.org/wiki/Race_condition
- http://en.wikipedia.org/wiki/Thread_%28computer_science%29
- http://en.wikipedia.org/wiki/Command_pattern
- http://en.wikipedia.org/wiki/CRUD_%28acronym%29
- http://en.wikipedia.org/wiki/Busy_wait
- http://en.wikipedia.org/wiki/Representational_State_Transfer
- http://en.wikipedia.org/wiki/Cooperative_multitasking
- http://en.wikipedia.org/wiki/Coroutines
- http://en.wikipedia.org/wiki/Model-view-controller
- http://en.wikipedia.org/wiki/Document_Object_Model
- http://en.wikipedia.org/wiki/XMLHttpRequest
- http://jsdoc.sourceforge.net/
- http://www.polyglotinc.com/Gravy/
- http://www.polyglotinc.com/AJAXscratch/Mutex/examples/
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.
IE 7
Firefox 2.0
