Christmas 2009

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

0

The 2009 Advent Calendar Wrap Up

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…

0

Final code version for 2009 Advent Calendar

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.ReleaseMutex(); 13: } 14:…

0

2009 Advent Calendar December 24th

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…

0

2009 Advent Calendar December 23rd

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 { get; private set; }…

0

2009 Advent Calendar December 22nd

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 WaitOne() 8: { 9: ++NumberOfLocks; 10: } 11:  …

0

2009 Advent Calendar December 21st

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: }…

0

2009 Advent Calendar December 20th

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

0

2009 Advent Calendar December 19th

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…

2

2009 Advent Calendar December 18th

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: { 9: _thread = new Thread(() => 10: { 11: _lock.Lock(); 12:…

0