Arrrrr! Cap’n Eric be learnin’ about threadin’ the harrrrd way

Avast ye scurvy dogs, it be National Talk Like A Pirate Day!

A scurvy bilge rat commented on the preceding discussion about putting apartment threaded objects in Session scope:

back in the era of the NT4 Option Pack I wrote a lot of code that involved stashing Scripting.Dictionary objects in both session and application scope. [...] I forget now which version of the runtime changed the threading model they were registered with and broke everything for me.

Shiver me timbers! That be my fault. Sorry about that. When you create an ActiveX object, the COM runtime code checks the registry to see if the object is marked as participating in the Apartment, Free or Both threading models.  (We'll go into the difference between Free and Both at another time.)

Now, when I was a young swabbie seven years ago I was given the task of implementing the Scripting.Dictionary object, and I didn't yet understand all the stuff I just told you maties about threading.  In one build that was released to the public I accidentally marked the dictionary as Both, even though it is a Single Threaded Apartment object. So when lubbers would put a dictionary into Session scope, it would be called by multiple threads at multiple times, in violation of the apartment contract.  As long as there were only readers, it was generally OK, but as soon as there were readers and writers, it would usually crash and die.

And of course when we corrected the mistake, all those pages went from sometimes-crashing-but-fast to not-crashing-but-slow. That was my first majorly customer-impacting mistake, and probably the worst I ever personally made. 

Speaking of mistakes, there was another interesting performance mistake in early releases of the Scripting.Dictionary object. It uses a very simple hash table for rapid lookup, but of course hash tables require that the hash function distribute hashes broadly given a narrow distribution of keys.  I screwed up the hash algorithm, and one of the consequences was that hashing on a string consisting of five digits was likely to go to a very small number of hash buckets.  

We discovered all this the day that decided to store every zip code in the United States in a Scripting.Dictionary object in Session scope!  Perf of went way south, way fast.

The combination of the two mistakes above led the ASP team to write their own string table object, that really was Both threaded and blindingly fast. Arr!

Comments (11)
  1. So yer the bilge rat who caused that! I meant to ask you about it, arrr. To this day I be not using dictionary object because of a bad experience with it building some scurvy shopping carts.

    When I boarded Microsoft a few years back for some Commerce Server demos, I asked a mate there about that bug (and if it still existed). He was most scurvy in his reply. Yarrr.

    By the way, why was "on error go to 0" not documented in earlier versions vbscript? Some lubber VB developer suggested that I try it, and I was very surprized back than that it worked. Were there any other undocumented scurvy features like that? What about easter eggs? Aarr.

  2. Arrr! Havin’ spilled the beans, swabby, you best be protectin’ ye precious cannon balls from enemy swords. Many a tall ship crashed on the rocks of the scripting.dictionary. Aye, she was a most narly beast, for sure.

    So, how did a green eared bilge monkey (I mean that in the nicest piratey way) like you come to possess the scripting.dictionary beast with nary a review by a superior officer? The captain must surely have been afire that day with many unruly mates on the plank, no?

    Well, bygones begone, mate! Let’s heave a pint with a merry yo ho to brave Lippert’s mighty confession this day!

  3. Eric Lippert says:


    > why was "on error go to 0" not documented in earlier versions vbscript?

    Arr, you have to keep in mind that the VBScript documentation "team" at the time was one guy. Actually, not even one guy — Fred spent some time documenting other stuff as well I believe. Now, don’t get me wrong — Fred was a great guy, a lot of fun to work with, and very competent. But there simply was not enough time, budget and manpower to do a really proper job on the script engine documentation. A few things fell through the cracks now and then.

    Documentation is EXTREMELY expensive. Writing it the first time is not so bad. Translating every page into 26 languages, that gets real expensive real fast.

    > So, how did you come to possess the scripting.dictionary beast with nary a review by a superior officer?

    Arr, we certainly had code reviews, but the script team in the early days was pretty cowboyish. The thing is that the dictionary object shared its registration code with an object that really WAS Both threaded — in that situation even experienced code reviewers fall into the trap of "this code has been reviewed before, we can skip reviewing it this time." As time went on we became more and more hard core about reviewing every line of every change.

  4. Jenda says:

    "The combination of the two mistakes above led the ASP team to write their own string table object, that really was Both threaded and blindingly fast." ???

    Where can we get the beast? Or did I misunderstood something?

  5. Eric Lippert says:

    It used to be available for download on the MSDN page — like, five years ago — but I cannot find it now. I’m not sure what became of it. If I recall correctly, it was in strtable.dll.

  6. Oorf says:

    Perhaps you meant the Lookup Table Component?

    "The Lookup Table Component is an Active Server Pages component that provides an efficient read-only lookup table of string (or integer) values and string (or integer) keys. It offers better performance than the default VBScript Dictionary Object, especially in session and application scope."

  7. Andy McFly says:

    >> why was "on error go to 0" not documented in earlier versions vbscript?

    >Arr, you have to keep in mind that the

    >VBScript documentation "team" at the time was

    >one guy. Actually, not even one guy — Fred

    >spent some time documenting other stuff as

    >well I believe. Now, don’t get me wrong —

    >Fred was a great guy, a lot of fun to work

    >with, and very competent.

    Damn you Fred…if I could only get my DeLorean time machine out of the flux capacitor repair shop I would go back in time and offer to help your documentation efforts. Many, Many, Many, MANY a days and night have been spent on mine and other folks tracking down crappy code with the infamous "ON ERROR RESUME NEXT"…had some of these folks only known about "ON ERROR GOTO 0", maybe we could have ended world hunger or something more today.

    Would be cool if MS maybe starts picking up on the WIKI help/documentation idea like PHP and others…at least during RC days so folks can really start to point out inconsistances.

  8. Andy McFly says:

    Exactly like that…tell Mr. Carter to keep fighting the good fight 🙂

  9. Saiyan Vejita says:

    ARR! So ye be the scurvy squad what made yon Dictionary object walk th’ plank! If I was a younger man, I’d a’ strung ya up and keelhauled ye afterwards!

    Seriously, though — as much of a mistake that was, it’s good to see that you’re willing to owe up to it. It’s probably not proof against making an even bigger and more far-reaching mistake, but it also says a lot about the caliber of person you are.

    Have you yourself ever used any third-party components to replace the Dictionary object, that are also thread-safe? And if so, which one(s)?

  10. Morten Grøtan says:

    At my company we excavated the whole Internet in order to (not) find the infamous LookupTable component. Anyway, it was based on loading a text file (brrrrhh…), so we went for something more pro. Take a look at this bugger:

Comments are closed.

Skip to main content