related sites: <FREE Help> <ASP> <Asp.net> <worldwide> feedback: <lovethat> <hatethat> <thanks> <credits> <contact us>
Thread Safety Issues by Charles Carroll with some help from George Reilly
All the work done by a webserver is handled by threads. They are the worker bees of the webserver. Any process running on the webserver runs on a given thread. Threads can affect ASP in several ways, see:
We will focus on Thread Safety issues here.
What is Thread Safety?
If a program gets called very fast it can crash or burn out it's motor like a car driven at a high speed UNLESS the designer built in some pretty aggressive code to deal with speed and tested it (kind of like the cars that get run into a wall with crash dummies) Thread safety and high scalability is usually only accomplished by EXTREMELY experienced programmers or commercial components. Thread safety means that the insides were built for speed and then actually tested by creating intense loads (the equivalent of crashing cars into walls) with tools like the Stress Tool at http://homer.rte.microsoft.com/. Better they do this and find out before someone hits a wall and dies the insides need re-inforcement.
A component that is not thread-safe
Crashes or contributes to system instability if the usage pattern creates a situation where several users concurrently access the component in same millisecond.
Leaks memory and/or places locks on resources in subtle-ways and/or does not behave predictably when many objects are running round-robin. The registry may have settings that indicate it is safe to be invoked many times from many clients and marked and FREE threaded or both, the programmer due to inexperience or lack of stress testing did not truly do the locks, synchronization, memory protection, critical section code they thought they did.
Test for Thread Safety with WAST - Not People
Thread Safety testing on home-grown components can be done with tools like the Web Application Stress Tool see: http://www.asplists.com/asplists/aspwast.asp Thread Safety issues are more likely to be discovered on multiprocessor machines and that it's vital to stress test components on MP machines to ensure thread safety.
WinInet: Not Thread Safe
The WinInet control is a popular way Visual Basic programmers use to scrape web sites. It however was not tested for server use and had some serious flaws that caused it to create many runtime disasters.
http://support.microsoft.com/support/kb/articles/Q188/9/55.ASP explains how it could be used in ASP with light load.
http://support.microsoft.com/support/kb/articles/Q183/1/10.ASP http://support.microsoft.com/support/kb/articles/Q238/4/25.ASP explains about Thread-Safe issues.
Other articles can be found by searching for kbWinInet (kbASP can be added to qualify it)
http://support.microsoft.com/support/kb/articles/q237/9/06.asp
Thread Safe WinInet Alternatives
Three alternatives to WinInet exist.
Microsoft finally created a server side HTTP component in MSXML3.0: http://msdn.microsoft.com/xml/general/xmlparser.asp
ASPHTTP from www.Serverobjects.com is an example of a very safe implementation.
ASPTear from http://www.alphasierrapapa.com/ComponentCenter/ is built on WinInet but the designer Christophe Wille has assured me it wrapped it in thread safe C code to skirt the thread safety problems.
Dictionaries - Threading Problems in App or Session Vars
The scripting dictionary is useful but if used at session or application scope can be slow and prohibit scalability in terms of serialization and resource issues.
A FREE replacement interface compatible component can be found at: http://www.caprockconsulting.com/comsoftware.asp
http://msdn.microsoft.com/workshop/management/planning/msdnchronicles2.asp explains how Microsoft had difficulty with scalability at session scope on their site.
http://msdn.microsoft.com/library/techart/d4cache.htm demonstrates a useful page caching technique.
http://support.microsoft.com/support/kb/articles/Q194/8/03.ASP discusses using it as application scope object.
This is only a problem with the original Windows Option Pack. It's fixed in later service packs and Win2K and it's fixed in everything that installs more recent script engines.
Also an important note for people who have installed WinNT Option Pack 4 to run ASP*: /iishelp/iis/htm/core/iisread.htm
The Scripting.Dictionary object is erroneously marked as Both-threaded. It should be marked as Apartment-threaded. To change this, use the Registry Editor to open the following registry key: HKEY_CLASSES_ROOT\ CLSID \{EE09B103-97E0-11CF-978F-00A02463E06F} \InprocServer32
Change the named value for ThreadingModel to Apartment. If you use the Dictionary object at Application scope without making this change, corruption of data may occur.
Thread-Safety Issues Table of Contents PrintView <Previous> Thread Basics CL1 webserver: <Anantsystems> <Ad info> related sites: <FREE Help> <ASP> <Asp.net> <worldwide> feedback: <lovethat> <hatethat> <thanks> <credits> <contact us>