A very common mistake taken by junior ASP.NET developers is forgetting that any web application running in a IIS instance will most likely run in a multithread environment.
They forgot that, unlike the dev environment which usually runs in a single thread pool, production environment usually have a working thread pool with several dozen threads.
Common mechanism like the ASP.NET Cache or the ASP.NET Session have points of concurrency.
It’s common to create singletons in web apps. The most common scenario are provider pattern implementations. Many times, apps also need to have it’s own Cache mechanism or even Session mechanism. All this scenarios may leads us to multi thread racing for some resources.
Testing those code pieces were almost impossible … and multithread bugs and deadlocks were detected late in the application developing cycle:
- when running load tests
- or, in the worst scenario, only in a production environment.
This new tool is intended to help finding and fixing possible deadlocks by enabling us to write threaded tests.
And if you think that this is a complex task to do, you are wrong. Doing race tests is as simple as writing a unit test and then decorate it with an attribute – [ParallelInspection].
That’s it .. you can then run the test and Racer will try to find and recreate deadlocks.
In future Racer will also check for race conditions.
Take a look at this Roy Osherove post for some snapshots and a little movie.