This time, Joe Developer thinks he found a bug in the .NET framework. Joe read that the volatile modifier is "usually used for a field that is accessed by multiple threads without using the lock Statement". Joe wants to try this out, and writes the following class.
This code ran successfully at least a dozen times, then suddenly blew up with the following exception:
System.ArgumentException was unhandled
Message="Destination array was not long enough.
Check destIndex and length, and the array's lower bounds."
Source="mscorlib"
ParamName=""
StackTrace:
at System.Array.Copy ...
at System.Collections.Generic.Queue`1.SetCapacity ...
at System.Collections.Generic.Queue`1.Enqueue ...
at Worker.PopulateQueue ...
...
Joe thinks something has gone terribly wrong in the CLR, and for once, Joe would like to show his boss a problem in someone else's software. What should his boss think?
Someone asked me if the "asynchronous" in AJAX means we should be worried about thread safety and global variables in client-side script. This is an interesting question to ponder.
A search of the ECMAScript language specification returns zero hits for the word "thread". JavaScript, like C++, appears to leave threads as an implementation detail. There are no keywords or intrinsic ECMAScript objects available to manage threads, or to provide for thread synchronization.
I find it strange that there are articles like "Implementing Mutual Exclusion For AJAX" claiming to control threads. Some of these articles assert that integer assignment in JavaScript is an atomic operation. I've yet to see documentation that proves this assertion and I'm wary of this claim given the number of software layers between the scripting runtime and the hardware.
I don't think we are in a position to even worry about concurrent threads in script. With no mechanism to control threads, we have to trust our browsers to "do the right thing". IE7 appears to use a single thread for executing script code in a page. Based on experiments with the native debugger and Winspector, the thread appears to be a message-pumping UI thread. I'd have to assume that other browsers (at least on Windows) also follow a single threaded model for simplicity. I have no proof, so any insight readers can provide would be appreciated.
In trying to confirm this behavior, I came across a 2003 post by Eric Lippert: "What are "threading models", and what threading model do the script engines use?". Here is a juicy excerpt:
* When the script engine is in a state where it cannot possibly call an ActiveX object -- for instance, if it has just been created and has not started running code, or if it is just about to be shut down -- then the script engine really is free threaded, but who cares? It can't do much in this state.
* When the script engine is initialized -- when the script engine host has started the process of passing code and object model state to the engine -- the script engine morphs into an apartment threaded object. All calls to the script engine must be on the initializing thread until the script engine is shut down again.
Eric then muddies the water in a later comment:
It's very difficult to do true multi-threading inside IE. However, there are clever things you can do with the setTimeout method. I've also been thinking that it might be interesting to describe setTimeout from a continuation-passing-style perspective.
It doesn't appear that Eric ever followed up on this comment, unfortunately.
But what about the A in AJAX? Assuming xmlHttp is a native object it is free to use any number of background threads to free up the browser's UI. When xmlHttp raises an event, however, that call must marshal to the thread responsible for executing script.
I do wonder what this single threaded model means for the future. As the amount of script code for AJAX and WPF/E grows, this model has the potential of being a bottleneck.
A couple months ago, I shared a ride to the Dallas airport with my friend Walt Ritscher. I remember Walt was excited about WPF and WPF/E - so excited it seems he now has a blog dedicated to the topic: WPF Wonderland.
Walt added some west coast flair to my WPF/E Game Of Life code and hosted the sample. You can give it a whirl if you have the December 2006 WPF/E CTP installed.
I've seen the following model popup frequently:
This is an ASP.NET MasterPage with a content placeholder wrapped inside an UpdatePanel. A menu control provides links to default.aspx and default2.aspx - both content pages that use this master page.
The misconception is that the update panel will magically reload only the area inside the ContentPlaceHolder control when the user clicks on a navigation link in the menu. This example uses a menu, but we could substitute any type of control that generates hyperlinks to a new page. Since both pages use the same master page, this behavior seems plausible.
The behavior described above isn't how AJAX and MasterPages work, however.
First, the hyperlink forces the browser to navigate to an entirely new page. There is no opportunity for the partial page rendering magic of AJAX to work. When the user clicks a navigational link, the browser will load 100% of the new page. If you want to update just the content area then you need the browser to stay on the same content page.
Secondly, ASP.NET always mashes the MasterPage and ContentPage into a single piece of output. From the client browser's perspective, it's all coming from the same resource. Each new page request will require ASP.NET to recreate both the master page and content page (assuming there is no caching). If you want to embed the contents of a new page into an existing page, then HTML IFRAME element still wants to be your friend.
Some might say it's a day late, but nevertheless, it is a message. And it's for you.
Of course, you'll have to figure out what the message is by reading the source code. This year's code isn't quite as ugly as last year's code, but if you can figure this one out without a compiler - three cheers! If you do figure it out, you might still want to run the code as a console application to see the full effect...
A couple people asked me how my WPF/E port of Life turned out.
Answer: it works pretty well. Here is the source code if you want to look. I built the project with an .aspx page, although I don't use any server side logic and the page could easily be plain HTML. The XAML is not fancy Expression built XAML. In fact, the board is mostly built inside script. There is just enough XAML to bootstrap the board.
I'm looking forward to future releases.