Whenever I encounter a scenario that I know will benefit from the power of asynchronous multiple threads, I still dread the implementation. Concurrent programming stretches my brain and patience in many ways as things which just seem like they should work end up working not at all, or even worse: code that runs smoothly for 99 out of 100 scenarios but sneaks up to bite at the last moment, when it turns out that what you thought was thread-safe really was not at all.

The other day I had encountered such a scenario. I found it necessary to write a stand-alone application which had the capability of acting as a server and responding to events on the local network so that it could be controlled remotely. In general terms, the application consisted of the following components:

1. Server: The main class, responsible for making the network connections
2. ServerThread: Started and referenced by Server, to listen for incoming events on the opened connections
3. OtherClass1 … OtherClassN: Classes which contain the application’s actual functionality

The goal was to not integrate networking junk throughout the whole application, by instead having network requests captured by the ServerThread and delegated to listeners. This would allow the network interface and the program’s functionality (OtherClassN’s) to be decoupled from the guts of the network connection.

1. (setup) Server initiates connection, starts ServerThread, registers itself as a listener
2. ServerThread (producer) receives an incoming request, and fires an event to all listeners
3. Server (consumer) receives event delegates accordingly to OtherClass
4. ServerThread returns to listening
5. OtherClass does its thing

If you have written multithreaded applications, you will probably spot the problem with this approach quickly. However, my first attempt at this (shown below) actually worked fine until the ServerThread received and fired an event such as “exit” to its listeners, whereupon my program would invoke a ConcurrentAccessException and go unresponsive. I tracked this error down to it being caused by a simultaneous attempt by ServerThread to loop through the array of IListener interfaces, and the attempt by a notified listener to remove itself from the list before ServerThread had finished looping through the list to notify the remaining listeners.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

class BadProducer extends Thread {
	//
	// Network object declarations here
	// ...
 
	List< IListener > listeners = new ArrayList< IListener >();
	Object listenerLock = new Object();
 
	boolean stop = false;
 
	public void addListener( IListener listener ) {
		sychronized ( listenerLock ) {
			listeners.add( listener );
		}
	}
 
	public void removeListener( IListener listener ) {
		synchronized ( listenerLock ) {
			if ( listeners.contains( listener ) )
				listeners.remove( listener );
			}
		}
	}
 
	public void fireEvent( String szMessage ) {
		synchronized ( listenerLock ) {
			for ( IListener l : listeners ) {
				l.addMessage( szMessage );
			}
		}
	}
 
	public void run() {
		while( !stop ) {
			String szLast = reader.getLine();
 
			fireEvent( szLast );
		}
	}
}
 
class BadConsumer implements IListener {
	private BadProducer serverThread;
	private SomeClass c;
 
	/*
	 * Implemented from IListener
	 */
 
	public void addMessage( String szMessage ) {
		//
		// Handle message directly
		//
		if ( szMessage.equals( "whatever" ) ) {
			// works fine as long as we don't call into serverThread!
			c.doWhatever();
		}
		else if ( szMessage.equals( "exit" ) ) {
			// throws Concurrent Exception
			serverThread.removeListener( this );
		}
	}
 
	public static void main( String[] args ) {
		serverThread.join();
	}
}

Fine, I thought, I’ll make sure to lock the array of IListeners with a synchronize {} block. But the exception was still thrown. Upon begging the advice of one of my coworkers, and examining the logic of my code, I realized that calling another’s thread’s method (in this case, from ServerThread to server) transfers control of execution to that thread, which then releases the lock internally. When Server attempts to call removeListener( this ), it throws an exception.

The solution is a based upon a concurrency pattern called Consumer-Producer. The key reason why this works where the other didn’t is that when ServerThread calls fireEvent(), the IListener responds asynchronously to that event as well. This allows execution to return immediately to serverThread, so that its lock is still maintained. Meanwhile, the server class runs a loop of its own, occaisonally checking for a new message in an vector of its own. (Introducing a vector allows flexibility and data integrity in the case that ServerThread receives multiple requests before Server has handled the last one, acting like a message queue). This is as clear as mud conceptually — so here’s the modified source code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67

class Consumer extends Thread implements IListener {
	//
	// Server object declarations here
	// ...
 
	private Vector< String > messageQueue = new Vector< String >();
	private Object mqLock = new Object();
 
	public void messageLoop() {
		while ( true ) {
			String szNextMessage = "";
 
			// Check for messages
			synchronized ( mqLock ) {
				if ( messageQueue.size() > 0 ) {
					szNextMessage = messageQueue.getItem( 0 );
				}
			}
 
			if ( szNextMessage != "" ) {
				// Handle message
				// ...
				//
			}
 
			// Don't lock the producer out
			sleep( 50 );
		}
	}
 
	/*
	 * Implemented from IListener
	 */
	public void addMessage( String message ) {
		synchronized ( mqLock ) {
			messageQueue.add( message );
		}
	}
 
	protected void run() {
		messageLoop();
	}
}
 
class Producer extends Thread {
	private boolean stop = false;
 
	private List< IListener > listeners = new ArrayList< IListener >();
 
	public void checkForClientMessages() {
		while ( !stop ) {
			String sz = reader.readLine();
 
			fireEvent( sz );
		}
	}
 
	private void fireEvent( String event ) {
		for ( IListener l : listeners ) {
			l.addMessage( event );
		}
	}
 
	protected void run() {
		checkForClientMessages();
	}
}

The new flow resembles the following:

1. ServerThread receives an incoming request, calls fireEvent() to all listeners
2. ServerThread releases lock and returns to listening
3. Server, looping on its own thread, notices an new message in the message queue.
4. Server gets the next message from the queue and releases its lock
5. Server interprets the event and delegates accordingly
6. Server sleeps, then checks the queue again. Meanwhile, ServerThread may have received several events and added them to the message queue, but without having to stop and wait for Server to handle them.

The new model responded well under testing, even with rapid-fire requests sent with the intent to bog it down. The vector (message queue) acts as a buffer between those events and the event handler, which allows for asynchronous handling. And best of all: no exceptions!

I’ve been fiddling with COM components lately, trying to set up a simple server application that allows late binding so that I can call the API from languages other than C/C++, but I soon ran into an interesting permissions problem when trying to register the object for the second time (don’t ask): RegCreateKeyEx in my DllRegisterServer() function was returning ERROR_ACCESS_DENIED (5) even though I was running an account with administrative rights. I found this rather puzzling, and the worst part was that regsvr32.exe returned with a misleading success message.

After some Googling, I ran across an article which suggested that I change the permissions of the HKCR and HKCR\CLSID registry keys. I eventually did this, explicitly enabling full control to both them and their sub-keys for all users,  but with no success. The solution, I eventually found, was to launch Visual Studio itself in administrative mode, which did the trick (maybe this should have been my first step, but hey, my account is an admin account!).

After all this, it seems to me that registering a COM component shouldn’t require administrative access; at the very least, it would be nice if I just had to confirm the registry change — which I would like to think User Account Control would be capable of discerning. Also, because I didn’t have any sort of problem registering the component for the first time (I was running Vista at the time), I kind of wonder if this is a Windows 7 RC fluke or just an intentional permissions lock-down on the new-and-improved version of UAC.

Update: Disabling UAC completely also allowed the component to register.

A quick tip on the side (not my own): Note that I have VS set up to use regsvr32.exe to “run” the debug profile so that the code can be debugged within the IDE. To do this, open the properties page for your COM server project, click on the debugging section, enter “regsvr32.exe” into the Command box, and “”$(TargetPath)”" into  Command Arguments (you need one pair of quotes for the latter).

Another seasoned (read: old-ish) but fantastically practical book for programming students, enthusiasts, or pros looking to improve their ability is The Pragmatic Programmer by Andrew Hunt and David Thomas. I stumbled onto this one while browsing randomly through the local bookstore, and I’m glad I discovered it. If you are serious about software development as a career, I’m convinced that you will benefit from owning this book.

Although Pragmatic Programmer has plenty of expected how-to best coding practices, such as orthogonality, code generation, object orientation, and other tips designed to save you time in the long run, the overarching theme of the book rises above; this theme is something the authors refer to as the DRY Principle – that is, “Don’t Repeat Yourself.” The book bullet-points a total of 22 bluntly succinct tips (these tips are also collected into a quick-reference tear out sheet in the back of the book), and most of these involve concepts to help you fulfill the DRY principle. Though the book is highly conceptual, Hunt and Thomas include a few brief code snippets to make those tips tangible (my only wish is that they could be fleshed out a bit more).

One of the coolest things about the book, in my opinion, is that the authors have made an effort to cover nearly all the aspects of the software development process — from gathering requirements, writing prototypes and tracer code, to coding,  testing, debugging, deploying, and writing documentation — brushing each against the DRY goal of non-duplication. This thorough book also includes some out-of-the ordinary sections, such as how to understand algorithm speed and performance. Hacking code, I am realizing,  is only a part of the big picture in a successful project!

Some of the suggestions are harder to put into practice than others (such as learning scripting languages to automate routine tasks, and taking the time to learn powerful text editors like Emacs or Vim which have keyboard shortcuts for everything up to organizing a world takeover), but I have no doubt that once the initial time investment is made in learning a scripting language or two, it will pay itself back many times over. I find myself preferring, and ultimately relying perhaps a bit too much on comfy IDE’s and UI’s and costing myself time and wasted mouse manuevering in the long run for the convenience and viewing pleasure. (For the record, though, I’m hooked on the Eclipse editor and I’m not budging!)

In short, it’s hard to read a section without being slightly convicted in one way or the other about things we all should already know (yes, you have to comment your code; yes, you have to document it; and no, your team shouldn’t allow anonymous code). But the topics quickly progress beyond these points and into many other, less obvious, tips and warnings. Hunt and Thomas have drawn from their experience and have done a great job in combining so many great principles into a book that is easy to read, humorous, and fluff-free (say that 5 times fast). Now if only I can gather up the courage to crush those lazy habits, and then tackle Perl and Latex…

Next up for review: Advanced Windows Debugging by Mario Hewardt and Daniel Pravat.

So with school officially out of the way for the year and a little time left before work begins, I dusted off my copy of Flex 3 the other day to re-learn the basics for a vague idea I had for an RI app. Flex seemed to have some pretty solid means by which to serve up and display data from a database fairly well, so I set out to try it out. The way it works is by POSTing a request to a simple server script (in this case written in PHP) which queries a specific backend database table, returning the list of records in the table as XML. Adding new records to the table and modifying existing ones are accomplished in exactly the same way, just with slightly modified server scripts for each operation. Using the data binding features that Flex provides, hooking up to this data and displaying it in a DataProvider is a peice of cake thanks to the HttpService class (there are plenty of examples of this process on the ‘net).

The problem arose, however, when I wanted to save rich text in HTML format to a specific field in the database. The rich text would save properly, but it would not redisplay since the tags were interpreted as XML themselves; this thoroughly confuses Flex which normally attempts to bind XML straight into a collection of objects for simple programmatic access. Here’s a screenshot of the raw server responses that it was choking over:

Instead of the HTML text between the <description></description> tags getting displayed properly, the cell showed a frustrating value of “[Object object],” with my HTML nowhere in sight (see screenshot below).

The solution for this is to bypass object binding — at least temporarily — and control the HTML before its containing node gets bound to an object. This involves traversing the XML structure as much as we dare; that is, up to the parent node and from there grabbing its internal text. Finally, using the ObjectProxy class, we can bind the HTML as the value to an XML node… converted to an object. In code, this looks like the following (notice that serv_result() is a callback for HttpServer’s ResultEvent):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

<mx:Script>
      <![CDATA[
		[Bindable]
		private var _noteList:ArrayCollection;
 
		private function serv_result(evt:ResultEvent):void {
			var xmlStr:String = evt.result.toString();
			var xmlDoc:XMLDocument = new XMLDocument(xmlStr);
			var note:ObjectProxy;
 
			_noteList = new ArrayCollection();
 
			for each (var n:XMLNode in xmlDoc.childNodes[0].childNodes) {
				var szDescription:String = n.childNodes[1].toString();
 
				var indexFirstBracket:Number, indexLastBracket:Number;
				indexFirstBracket = indexLastBracket = -1;
 
				indexFirstBracket = szDescription.indexOf(">");
				if (indexFirstBracket != -1) {
					szDescription = szDescription.substr(indexFirstBracket+1, szDescription.length-indexFirstBracket-1);
				}
				indexLastBracket = szDescription.lastIndexOf("<");
				if (indexLastBracket != -1) {
					szDescription = szDescription.substr(0, indexLastBracket);
				}
 
				var next:Object = { title:szTitle,
									description:szDescription,
									question:szQuestion,
									startdate:szStartdate,
									enddate:szEnddate,
									imageurl:szImageurl};
 
				note = new ObjectProxy(next);
				_noteList.addItem(note);
			}
 
			notes.dataProvider = _noteList;
		}
 
		private function initCellRenderer():void {
			description.itemRenderer = new ClassFactory(HtmlRenderer);
		}
	]]>
</mx:Script>
 
<mx:DataGrid id="notes" x="10" y="46" height="544" width="780" initialize="initCellRenderer()" change="updateButtons()">
	<mx:columns>
		<mx:DataGridColumn headerText="Content" id="description" dataField="description" width="250" />
	</mx:columns>
</mx:DataGrid>

You can see that we are managing a small step of the binding process ourselves to prevent Flex from parsing the HTML and trying to bind it to an object (which fails and just results in the “[Object object]” text). Note that in order for this to work you must set the resultFormat property of your instance of HttpService to “xml” (the default is “object”).

As you may have guessed from the initCellRenderer() function, a custom cell rendering component is necessary in order to display an HTML-capable widget, but this is the most trivial part of the process:

1
2
3
4
5
6
7
8
9
10
11
12
13

// HtmlRenderer.mxml
<?xml version="1.0" encoding="utf-8"?>
<mx:VBox xmlns:mx="http://www.adobe.com/2006/mxml" width="100%" height="140" 
	paddingBottom="5" paddingLeft="5" paddingRight="5" paddingTop="5">
<mx:Script>
	<![CDATA[
		import mx.controls.Alert;
	]]>
</mx:Script>
	<mx:TextArea id="htmltext" htmlText="{data.description}" height="100%"
		width="100%" backgroundAlpha="0" focusAlpha="0" wordWrap="true"
		borderThickness="0"/>
</mx:VBox>

The results were better, but not quite perfect. As you can see from the capture above, the HTML was still getting “beautified” by the XML parser. In order to convince it to leave the HTML data alone, I ended up wrapping the HTML with quotes just prior to sending it to the database, and then removing those quotes before setting an HTML widget to its contents. The final results:

There you have it — embedded HTML in XML, bound to a Flex data view.