So I hope I showed you a way to BDD/TDD a thread safe solution without slow pesky tests that needs a number of helper threads to verify thread safety. Also, you’re not guaranteed that your code is thread safe just because of your tests when you use threads to try and break your code. You…

As I mentioned yesterday we now don’t have any tests for the MutexWrapper which is a thin wrapper for the Mutex implementation in .Net. I don’t think it is necessary to always have tests for these thin wrappers but sometimes it is a good idea to add a few tests just to verify that you’ve…

The change we did yesterday makes it possible to remove the use of helper threads and timeouts for the MutexLock tests. Here is a first refactoring: 1: public class Given_an_abandoned_lock 2: { 3: private class MutexWrapperAlwaysAbandoned : MutexWrapper 4: { 5: public new void WaitOne() 6: { 7: throw new AbandonedMutexException(); 8: } 9: }…

But wait! What happened yesterday? We added some significant functionality; hiding the fact that AbandonedMutexException might be thrown. Because of this I want to break out the Mutex implementation into a separate, thin wrapper for the Mutex object: 1: public class MutexWrapper 2: { 3: private readonly Mutex _lock = new Mutex(); 4: 5:…

So far so good but there is one more thing I want the MutexLock to do. The Mutex object may throw an exception (AbandonedMutexException) when being waited for if the current owning thread terminates without releasing the mutex. I want to hide that fact in my MutexLock so I don’t need to handle that exception…