This is the final version of all code created in the 2009 Advent Calendar: 1: public class MutexWrapper 2: { 3: private readonly Mutex _lock = new Mutex(); 4: 5: public virtual void WaitOne() 6: { 7: _lock.WaitOne(); 8: } 9: 10: public virtual void ReleaseMutex() 11: { 12: _lock...

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 can use something...

For easier reference, here are the 2009 advent calendar links: What problem and what do we start with ? Final thoughts and code . How: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

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 understood how...

And the last test refactored to remove the slow tests: 1: public class Given_a_locked_MutexLock 2: { 3: private class FakeMutexWrapper : MutexWrapper 4: { 5: public bool Locked { get; private set; } 6: 7: public static int NumberOfLocks { get; private set; } 8: public static int NumberOfUnlocks...

And today we refactor yet another test that is potentially slow when failing (because of the timeout): 1: public class Given_an_unlocked_MutexLock 2: { 3: private class MutexWrapperAlwaysUnlocked : MutexWrapper 4: { 5: public static int NumberOfLocks { get; set; } 6: 7: public override void...

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:...

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...

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...

Yet another passing test to make sure our MutexLock works as expected: 1: public class Given_a_locked_MutexLock : IDisposable 2: { 3: private MutexLock _lock = new MutexLock(); 4: private Thread _thread; 5: private bool _gotLock = false ; 6: 7: public Given_a_locked_MutexLock() 8: { ...

Since we already have an implementation for the MutexLock I want to add another passing test: 1: public class Given_a_locked_MutexLock : IDisposable 2: { 3: private MutexLock _lock = new MutexLock(); 4: private Thread _thread; 5: private bool _gotLock = false ; 6: 7: public Given_a_locked_MutexLock...

So far I'm pretty pleased with how the ImportantObject is protected by the ImportantProvider but we're dealing with thread safety and how can we be sure the MutexLock class really does what it is supposed to do? We should put that class under its own set of tests. So let's start with a simple one: 1...

So instead of the generic for the lock we had yesterday we can add a default constructor for convenience in the code and keep the constructor injection for the test code: 1: public class ImportantProvider<T> where T : ImportantInterface, new () 2: { 3: private T _importantObject = new T();...

But if we're using generics; why not do it for the lock too: 1: public class ImportantProvider<T,L> where T : ImportantInterface, new () where L : Lock, new () 2: { 3: private T _importantObject = new T(); 4: private L _lock = new L(); 5: 6: public Transaction Transaction 7: { 8...

One problem I see with how ImportantProvider turned out yesterday is that I have to give it the ImportantObject to provide. Hence I cannot be sure that all use of the ImportantObject is protected by the provider in the future. It is still too easy to bypass the thread safe ImportantProvider. We can fix...

So now we need to fix the broken ImportantProvider making sure it uses one lock: 1: public class Given_two_transactions_from_the_same_ImportantProvider 2: { 3: private FakeLock _lock; 4: private ImportantProvider _importantProvider; 5: private Transaction _transaction1; 6: private Transaction...

Like yesterday I only have a passing test to add today: 1: public class Given_two_transactions_from_the_same_ImportantProvider 2: { 3: private ImportantProvider _importantProvider; 4: private Transaction _transaction1; 5: private Transaction _transaction2; 6: 7: public Given_two_transactions_from_the_same_ImportantProvider...

Today I'm just adding a passing test. 1: public class Given_two_transactions_from_the_same_ImportantProvider 2: { 3: private ImportantProvider _importantProvider; 4: private Transaction _transaction1; 5: private Transaction _transaction2; 6: 7: public Given_two_transactions_from_the_same_ImportantProvider...

With the solution we have from yesterday we still have a big problem. Whoever uses ImportantObject must also create the transaction. That is really a bad idea since it is too easy to use the ImportantObject in an unsafe way (i.e. not using transactions at all). To fix this I'm going to introduce an ImportantProvider...

So far we've kind of assumed for most of the time that the ImportantObject is easy to create. If not you probably want to create an interface for the ImportantObject. And creating an interface is probably a good idea anyway. So this is a refactoring of all code we have from yesterday . 1: public interface...

Now that we have a working transaction from yesterday we need to add the important object to it. So let's use the initial implementation of the important object: 1: public class ImportantObject 2: { 3: public void ImportantMethod() 4: { 5: // Do things. 6: } 7: } Then we want a new...

Since I want the transaction we're creating to take the lock when created I also want to release the lock when the transaction is disposed: 1: public class When_using_a_transaction 2: { 3: class FakeLock : Lock 4: { 5: public bool IsLocked { get; private set; } 6: 7: public FakeLock() ...

Even though the solution created yesterday ensures thread safety when ImportantMethod is used I'm still not satisfied. It might be that I'm paranoid but when ImportantObject is changed in the future we don't really have any guarantee that the future developer remembers to keep things thread safe. For...

The problem with yesterday's solution is that we're only testing that the lock is taken when ImportantMethod is called. We don't know if the lock is taken before or after the code that is important to protect. So we have to do something about that. We can do that by extracting the important code in to...

Let's continue with the same lock interface and MutexLock implementation as yesterday . In order to switch from dependency injection using generics to a classical constructor injection we have to change the important object to something like this: 1: public class ImportantObject 2: { 3: private readonly...