Getting under the hood of ASP

This week we’re going to embark on explaining something that most of you know about, but from the letters we get, many of you would like to understand more thoroughly. That something is Active Server Pages (ASP), a method for creating dynamic Web pages that was invented by Microsoft and has started to spawn workalikes for non-Microsoft platforms.

This week we’re going to embark on explaining something that most of you know about, but from the letters we get, many of you would like to understand more thoroughly. That something is Active Server Pages (ASP), a method for creating dynamic Web pages that was invented by Microsoft and has started to spawn workalikes for non-Microsoft platforms.

First, a little history that will lead us off into the geeky depths of programming techniques: The background to ASP lies in Microsoft’s Internet Server API (ISAPI), which was created to overcome the problems caused by the Common Gateway Interface (CGI).

We discussed CGI some gazillion columns ago but let’s quickly recap: CGI is a mechanism by which an application on a Web server is launched on receipt of an HTTP request and is passed variables. The application executes, does whatever it does with the variables and optionally returns a datastream (usually in HTML format) to the sender of the original request. (The sender of the request is usually a Web browser, but it could be any application.)

The problem with CGI applications is that a separate instance of the application is launched for each request, each of which uses up memory and processor cycles. Because of this, CGI applications are usually resource hogs, so a heavily loaded CGI-based system doing real work such as driving a database-driven online shop can exhaust even the most powerful of servers.

Microsoft’s ISAPI attempted to solve the resource problem by using Dynamic Link Libraries (DLL). The DLLs are loaded into the Web server’s memory space, and by being “thread-safe” a single ISAPI DLL can support multiple requests.

We should take a short diversion here to explain what “thread-safe” means. A thread is a unique execution of a process using code that might be shared by other processes. Think of each thread as a different context of execution rather like several people reading the same book. One might be further ahead than another so each has the same process (book) but different contexts (places they are reading).

Note that a thread-safe environment doesn’t guarantee efficiency or reliability. This is because: a) while memory usage might be reduced the computational cost of thread switching (jumping from the context of one thread to the context of another and back again) might be significant; and b) you can’t guarantee that a thread-safe environment is reliable!

Now a program that is thread-safe has a) no race conditions; b) does not deadlock; c) has no priority failures; and d) no starvation failures.

A race condition means that multiple threads can read and write to the same memory. If a race condition exists, it can result in incorrect data being read and or written. When a race condition occurs, the result is usually catastrophic, with programs operating on meaningless data.

Deadlocks are a condition in which each thread in a group of threads gets stuck waiting for another thread in the group to finish what it is doing.

For example, Thread A locks access to a region of memory, M, and Thread B locks memory region N. Thread A then tries to copy M to N and can’t because B has N locked, and B tries to copy N to M and can’t because A already has locked M. As they are each waiting for the other to unlock its memory region, a deadlock occurs.

A priority failure occurs when a thread fails to complete its work before another thread needs the results. What happens to the dependent thread is determined by how the thread’s process performs error recovery – something that can be difficult or impossible in a multiple-thread environment.

In a computer-controlled cooling system, if Thread A needs the temperature to be available to set the heat output and Thread B hasn’t finished reading the temperature because its priority is low, Thread A will wind up frequently acting on old data. The result will be an oscillation around the target temperature value because of continuous over- and undershooting. This would not be a problem in a house, but in a nuclear power plant . . . well, we wouldn’t want to live near it.

Darn, we’ve run out of space, so suspend your Gearhead thread until next week.