Being Cellfish

Stuff I wished I've found in some blog (and sometimes did)

Browse by Tags

Tagged Content List
  • Blog Post: 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...
  • Blog Post: 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 can use something...
  • Blog Post: 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
  • Blog Post: 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 understood how...
  • Blog Post: 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...
  • Blog Post: 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...
  • Blog Post: 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:...
  • Blog Post: 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...
  • Blog Post: 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...
  • Blog Post: 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: { ...
  • Blog Post: 2009 Advent Calendar December 17th

    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...
  • Blog Post: 2009 Advent Calendar December 16th

    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...
  • Blog Post: 2009 Advent Calendar December 15th

    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();...
  • Blog Post: 2009 Advent Calendar December 14th

    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...
  • Blog Post: 2009 Advent Calendar December 13th

    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...
  • Blog Post: 2009 Advent Calendar December 12th

    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...
  • Blog Post: 2009 Advent Calendar December 11th

    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...
  • Blog Post: 2009 Advent Calendar December 10th

    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...
  • Blog Post: 2009 Advent Calendar December 9th

    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...
  • Blog Post: 2009 Advent Calendar December 8th

    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...
  • Blog Post: 2009 Advent Calendar December 7th

    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...
  • Blog Post: 2009 Advent Calendar December 6th

    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() ...
  • Blog Post: 2009 Advent Calendar December 5th

    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...
  • Blog Post: 2009 Advent Calendar December 4th

    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...
  • Blog Post: 2009 Advent Calendar December 3rd

    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...
Page 1 of 3 (57 items) 123