bling on software

Hmmm, I couldn’t really think of a good title except that this blog post has a little bit of everything of the title. As with any multithreaded program, deadlocks are a huge pain in the butt, and when they happen it costs time, money, and stress. In my code base I’ve introduced something called an ExtendedLock, which basically has something like this inside: 1: public class ExtendedLock : IExtendedLock { 2: public IDisposable Lock() { 3: while (!Monitor.TryEnter(this, 5000)) { 4: IncrementLockTime(); 5: } 6: return new Disposer(() => Release()); 7: } 8: public event Deadlock;9: } .csharpcode, .csharpcode pre { font-size: small; color: black; font-family: consolas, "Courier New", courier, monospace; background-color: #ffffff; /*white-space: pre;*/ } .csharpcode pre { margin: 0em; } .csharpcode .rem { color: #008000; } .csharpcode .kwrd { color: #0000ff; } .csharpcode .str { color: #006080; } .csharpcode .op { color: #0000c0; } .csharpcode .preproc { color: #cc6633; } .csharpcode .asp { background-color: #ffff00; } .csharpcode .html { color: #800000; } .csharpcode .attr { color: #ff0000; } .csharpcode .alt { background-color: #f4f4f4; width: 100%; margin: 0em; } .csharpcode .lnum { color: #606060; } Pretty simple.  IncrementLockTime, as the name implies keeps track of how long the current thread has been attempting to acquire the lock.  It returns a Disposer which takes an Action, which releases the lock.  This allows us to take advantage of the using syntax, and avoid boiler plate try/finally (oh, and it avoids typos in Monitor.Exit).  After some configurable amount of time, if the lock cannot be acquired within, say, 2 minutes, it’s probably a good probability your application is blocked somewhere. Read on...

Any search on the web you find will consistently show log4net outperforming EL by a factor of around 4:1.  Most of these tests are typically tight for/loops, and comments will end up saying things like “oh well that’s not a realistic test” or “well you shouldn’t be logging that much anyway”, etc etc.  Well, let’s see how important choosing your logging infrastructure is in terms of overall system performance in a multithreaded application. Read on...

I think anyone’s who has used ReSharper for an extended period of time has experienced the colors disappearing all of a sudden from Fonts & Colors. This is excruciatingly annoying when I have a dark color scheme set up and the colors disappear on me. In the case of RS5, it seems even more flakey than RS4, and installing/uninstalling other addins have a pretty high probability of losing the colors, and this time, repairing the installation doesn’t fix the problem (nor does the registry restore trick). Read on...

Having some significant experience with C++, every once in a while I’ll really miss features available in C++ that just aren’t possible in C#.  Sure, linking takes forever and if you could calculate the percentage of time for a C++ developer spent on linking time I’m sure it’d be around 50%.  Nonetheless, there’s a certain seductive pull to stepping through the debugger and the sheer speed of a C++ program (arguably debugger is being made obsolete with TDD).  If you’re only used C# for a long time, you probably didn’t even know that C++ was THAT much faster until you try this out.  Even a simple hello world program: you can tell a difference. Read on...

Unit testing is hard! I came to this sad realization when my code which had a large test suite with near 100% code coverage, with every thought-of requirement unit tested, failed during integration testing. How is that possible? I thought to myself. Easy…my unit tests were incomplete. Writing software is pretty complex stuff. This is pretty evident in the level of difficulty in determining how good a software developer is. Do you measure them based on lines of code? Read on...