Microsoft has made threading brain-dead easy to implement in the .Net framework.
For starters, every thread you allocate will consume a Meg of memory, right off the bat. In .Net 1.1, that 1MB was reserved, but not committed until the stack grows into it. In .Net 2.0, however, the CLR precommits the whole stack for reliability.
But the main problem n00bs deal with when implementing threading is not memory, but issues of concurrency. Each thread may be doing its own thing for the most part, but at some point its going to have to reach out and touch data outside of its little thread context.
But what if something else is already touching that data?
Mr. Mutex to the Rescue!
That’s where it gets tricky. And that’s where we might use a little something called a Mutex.
In .Net, a Mutex is implemented in the Mutex class. A Mutex is like a ball that gets passed from thread to thread. Whoever has the ball gets to run (and do stuff). If a thread doesn’t have the Mutex, it has to wait until it gets it.
To create a new Mutex you would just call it’s constructor thusly:
private static Mutex mut = new Mutex();
Up to this point we’ve just pulled a ball out of the locker room, so to speak. But nobody has it yet. From within a thread, we would call the WaitOne() method.
mut.WaitOne();
So the thread will sit here and wait, forever, if necessary, until it owns the Mutex. If it’s the first thread to call WaitOne(), the operating system gives it the ball and it does it’s thing. If it’s not the first thread, it waits and waits and waits, until another thread calls…
mut.ReleaseMutex();
…which, as it says, releases the Mutex. The thread is done with it… let another thread play for a while.
And this leads us to a very important point. A thread can call WaitOne() multiple times, but it must also call ReleaseMutex() the same number of times, or the Mutex won’t get released to other waiting threads. Which basically means your other threads that are waiting, waiting, waiting… will wait forever. Or until the “naughty” thread terminates (which, in .Net 2.0, will raise an AbandonedMutexException).
So a Mutex makes it relatively easy to control threading concurrency issues, although I’m sure some of you out there could concoct nasty horribly complex scenarios that would drive the sanest debugger mad. But you get the point.
Real World
So how ’bout a real world example? Code Toaster uses the SQLite embedded database engine to cache some of it’s Intellisense data. The problem with SQLite is that while you’re writing data, no other reads or writes can be made, or else an exception is thrown. Which is kinda stinky. SQLite doesn’t handle concurrency very well, does it?
But it is lightning fast, and works extremely well for something like Intellisense, where lots of data needs to be searched and retrieved almost instantaneously.
Since Code Toaster uses background threads to cache Intellisense information from assemblies and assembly documentation files, this was obviously a problem. More than one thread couldn’t write to the Intellisense database at once, lest an exception be thrown.
So naturally I used a Mutex to allow only one thread to write to the database at a time. Problem solved. Elegantly.
And lightning fast.
Posted by Bob Black 
Really. That’s what it said. Do not use this class. Lighten up Microsoft, I wasn’t going to use it, I just wanted to know what it’s for! Sheesh. And that’s pretty much all the documentation it looked like I was going to get on the infamous ShadowingAttribute.
Posted by Bob Black 
Parsing a template is comprised of three steps.
Posted by Bob Black 
