Unsafe thread safety
As I stated in my last post, for the past two days I've been sitting in Jeffrey Richter's threading class. The class is near the end and I can't say that a lot of new concepts have been taught. Another student and I have decided that the class should have been renamed, "Threading Basics". That's not to say anything of Richter's teaching skill or the content of the class. It just goes to show that if the architecture of a product is right, the threading code should be extremely simple to use.
However, what I love about this class is that it reminds me how much I enjoy this topic. The theory of the perfect architecture doesn't exist. Additionally, many times the developer has little-to-no ability to push back on a bad architecture. It's in these cases that you must use your bag of concurrency tricks to work out of the whole the architect(s) put you in. That sound easy enough, but what if the architecture included - *gasp* - "less-than-optimal" decisions in the actual .NET framework classes? What if those decisions were made in the very methods that are supposed to help you with these synchronization problems? These problems perplexed me when I first encountered them and I never really thought to blog about them (I was actually just scared I was doing something wrong). Taking this class gave me the perfect excuse to bring the topic up.
(continue)
