BackSpin
This month we’re going to embark on explaining Active Server Pages (ASP), a method for creating dynamic Web pages that was invented by Microsoft Corp. 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).
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. 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.
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.