|
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.
- behaves unstable when many clients are calling
it and it's behavior causes the callers damage since they assume each call
is safe and handling parameters correctly, etc.
- If they get hit hard and fail in some complex
way in some % of their requests, they don't recover gracefully and eat more
resources than normal and/or leave locks on memory, disk, resources, etc.
and never release them.
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.
A WinNT Option Pack 4 Dictionary Glitch
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.
|