At the time we had started the project, we were following the one test fixture per class convention and have since moved on to a scenario based specification style convention and have introduced a unit test base class that simplifies and increases our development velocity.

The goal of this post is to explain SpecificationFor<T>, our unit test base class, by building it step by step in a way that you can follow on at home.

We’re going to be using a sample class FormatterDecorator and it’s unit test fixture FormatterDecoratorFixture. Our decorator doesn’t do anything special, but should be complex enough to our needs.

public class FormatterDecorator : IFormatter {
  private readonly IFormatter _formatter;
  public FormatterDecorator(IFormatter formatter) {
    _formatter = formatter;
  }

  public string Format(string s) {
    return _formatter.Format(s);
  }
}

And here is the unit test fixture. Note we’re using NUnit for our testing framework and NSubstitute for mocks.

public class FormatterDecoratorFixture {
  private const string Formatted = "f";
  private const string Unformatted = "p";

  private IFormatter _formatter;
  private FormatDecorator _decorator;

  [SetUp]
  public void SetUp() {
    _formatter = Substitute.For<IFormatter>();
    _formatter.Format(Unformatted).Returns(Formatted);

    _decorator = new FormatterDecorator(_formatter);
  }

  [Test]
  public void FormatShouldReturnFormattedValue() {
    var result = _decorator.Format(Unformatted);
    Assert.That(result, Is.EqualTo(Formatted);
  }
}

The first thing we’re going to change is our convention for one unit test fixture per class. We’re going to move to a scenario based specification style. Fortunately for us, Dave has written a great post on moving to scenario based unit testing. Make sure to read it for the why.

To change to scenario based unit testing, we’re going to rename our test fixture class to match our scenario. For our example, the scenario we’re dealing with formatting, so we’re going to rename our class and filename from FormatterDecoratorFixture to WhenFormatting. If we had any additional scenarios for our class, we would move them into separate scenario based classes and files.

In order to support Resharper’s Navigate To Type feature for moving around our solution, we’re going to group each of the scenarios associated with our class into a FormatterDecoratorFixture outer class. Our new test fixture file should look something like below.

public partial class FormatterDecoratorFixture {
  public class WhenFormatting {
    // SetUp and Tests etc
    ....
  }
}

As we’re now working with an individual scenario for each test fixture, it makes sense to move the code that executes the scenario out of the test and into the setup.

  [SetUp]
  public void SetUp() {
    _formatter = Substitute.For();
    _formatter.Format(Unformatted).Returns(Formatted);

    _decorator = new FormatterDecorator(_formatter);
    _result = _decorator.Format(Unformatted);
  }

Now our SetUp method contains the code to initialise and execute our scenario. We can improve the situation by moving these into separate methods. First, we’ve got scenario setup code, our context. Let’s move this into a Context method. Second, we’ve got code that executes our scenario, let’s move this into a Because method.

  [SetUp]
  public void SetUp() {
    Context();
    Because();
  }

  private void Context() {
    _formatter = Substitute.For();
    _formatter.Format(Unformatted).Returns(Formatted);

    _decorator = new FormatterDecorator(_formatter);
  }

  private void Because() {
    _result = _decorator.Format(Unformatted);
  }

Our SetUp method is going to be the same for each scenario, so we can move that into a base class that each test fixture will inherit from. Let’s call this SpecificationFor.

public abstract class SpecificationFor {
  [SetUp]
  public void SetUp() {
    Context();
    Because();
  }

  protected virtual void Context() { }
  protected virtual void Because() { }
}

Now a lot of our contexts are going to be creating our subject (or class under test) and it’s dependencies (our substitutes). This is code that is going to be repeated for each scenario associated with a class. For example, if we added a new scenario for our decorator, we would need to duplicate the code that creates our _decorator subject and our _formatter substitute. We could move this code into a base class (i.e. FormatterDecoratorFixtureBase) and have each scenario inherit from that, but instead we’re going to introduce an auto mocker.

As we’re using StructureMap in our code base, it made sense to use the auto mocker built in. Jeremy Miller has a great post explaining the AutoMocker in StructureMap 2.5.

After introducing the auto mocker, our SpecificationFor now looks like this.

public abstract class SpecificationFor<TSubject> {
  private IAutoMocker _autoMocker;

  protected TSubject Subject {
    get { return _autoMocker.ClassUnderTest; }
  }

  [SetUp]
  public void SetUp() {
    _autoMocker = new NSubstituteAutoMocker<TSubject>()

    Context();
    Because();
  }

  protected T Resolve<T>() {
    return _autoMocker.Get<T>();
  }

  ...
}

With our auto mocker in place, our WhenFormatting scenario should be.

public partial class FormatterDecoratorFixture {
  public class WhenFormatting
    : SpecificationFor<FormatterDecorator> {
    private const string Formatted = "f";
    private const string Unformatted = "p";

    private string _result;

    public override void Context() {
      Resolve<IFormatter>().Format(Unformatted)
        .Returns(Formatted);
    }

    public override void Because() {
      _result = Subject.Format(Unformatted);
    }

    [Test]
    public void ShouldReturnFormattedValue() {
      Assert.That(_result, Is.EqualTo(Formatted);
    }
  }
}

Improvements that we can make to our SpecificationFor<T> are ensuring that the Subject is created before Because and to lazily initialise Subject to allow us to access it in our Context (should we need to set up the state of our subject or add event subscriptions etc). We can do this by wrapping the subject with a Lazy<T>.

public abstract class SpecificationFor<TSubject> {
  private IAutoMocker _autoMocker;
  private Lazy<T> _lazySubject;

  protected TSubject Subject {
    get { return _lazySubject.Value; }
  }

  [SetUp]
  public void SetUp() {
    _autoMocker = new NSubstituteAutoMocker<TSubject>()
    _lazySubject = new Lazy<T>(() => _autoMocker.ClassUnderTest);

    Context();
    EnsureSubjectIsCreated();
    Because();
  }

  private void EnsureSubjectIsCreated() {
    if (Subject == null) {
      throw new InvalidOperationException();
    }
  }

  ...
}

Using SpecificationFor<T> reduces mundane and repetitive setup code in our unit tests, gives us conventions for naming and placement of code. It’s been a big improvement for our productivity and our tests in general.

A surprisingly interesting session to kick off Agile 2009, Gilles presented on developmental stages on how we’re influenced by the stage we’re in.

There are seven leadership levels, with most of us being in the ‘Heroic’ stage (Expert & Achiever). Perhaps a little bit disheartening, Gilles has suggested that
only 10% of the population is capable of operating at the ‘Post-Heroic’ stage.

1. Opportunist
2. Diplomat
3. Expert
4. Achiever
5. Catalyst
6. Co-Creator
7. Synergist

There is an assumption that we move back and forth between the levels. For example, if we are stressed, we might slip back to the previous level. Also, the further developed you are, the quicker you are to adapt and the less defensive you are (less desire to hide your mistakes or need to know all of the answers).

Going from the heroic to the post-heroic stage requires a different mind set. A different way to think that is more strategic, more team focussed. An example is that a person at the heroic level will consider something a win if they manage to advance some aspect of themselves, we as a person in the post heroic stage will only consider something a win if they are able to advance some aspect of the entire team.

It was an interesting session and with the examples of the various levels, I was able to pinpoint myself somewhere between the Expert and the Achiever level, but I’ve noticed all too often that I’ll do something that that brings me back a level. Something I plan on working on for this year.

Craftsmanship wtih Robert Martin

Uncle Bob began the presentation by talking about how big plans don’t work, even if we’re wired to think they will. Actually, he started his talk with how electrons are fired form an electron gun through a filter and on to a screen to make a dot, but I can’t remember why now? Anyway, it came around to being about big plans and it all made sense at the time.

Big plans don’t work and even if we know it, there is a part of us that believes that if we plan enough, if we sit around this talk about everything we’ll get it covered and we’ll get it right this time. As much as we’re wired to believe that, it doesn’t work that way.

Complex systems that worked have invariably found to have evolved from a simple system that worked.
Complex systems that are designed from scratch never work and cannot be patched to make it work. Most people will start over, beginning with a simple working system.

Simple things live and evolve, complex things die a horrible and expensive death.

• Short iterations

  The consensus in the industry is that 1 to 2 weeks is the optimal iteration length. Bob believes that in a few years from now, this will drop to 3 to 5 days.

  What gets delivered at the end of the iteration? Something that is useful and delivers value to the customer. The customer does not have to agree that the functionality is complete but every iteration needs to deliver something that works.

  The Harvard Business Review had an article which concluded that the earlier you release, the happier your customers are, even if what you release is under-functioned.

• No grand redesigns

  We are the ones that made the mess and we must be the ones that clean up the mess.
  You don’ clean up your house by moving.

• Incremental improvement

  It’s not a technique, but a way of life.
  A commitment to never making the source code worse.

  We have the mess because we don’t practice incremental improvement; we practice incremental destruction. There should be no reason why
  a developer checks in source code in a worse state than they checked it out.

  Always improve the code as much as you can.
  Every time you make a mess you will slow yourself down.

  Big Dave Thomas’ law of continuos improvements is that progress is a
  sequence of decisions, some of them wrong.

• The only way to go fast is to go well
• Clean code

  Is an attitude, something that we commit to.

• TDD
• QA should find nothing

  Every time QA finds something, we should be asking ourselves how did this get out.

• 100% code coverage
• Avoid debugging
• Manual test scripts are immoral
• Definition of done

  All tests pass (unit, acceptance, UI etc), nothing less.

• Test through the right interface

  Business rules should be tested at the business layer, not the UI layer.
  You should test that the UI is wired up to your application, but do not drive your application from the UI tests.

  There should still be a few tests that drive all parts of your application from the UI, but these should be limited.

• Never be blocked

  Never say to yourself that I can’t move forward because…

Uncle Bob ended the session with a quick note on how craftsmanship does
not limit you from taking shortcuts. You can implement code with the
intention of removing it in the following iteration. However,
shortcuts must be clean.

This aligns with some of the thinking that I’ve been doing regarding the
advice of “simplest thing possible that will make the test pass”. I’ve heard, perhaps even uttered,
this phrase when justifying code that is not clean, not well factored.
Perhaps we need to replace the “simplest thing possible” with “simplest thing that isn’t crap” :)

Integration Tests are a Scam with J. B. Rainsberger

Hoping to get some answers to my questions regarding unit testing vs acceptance testing, I went a long to the session by J. B. (Joe) Rainsberger. However, as it turned out, the session was about integration tests, with integration tests being defined as defined as any test where the result of the test depends on more than one object being correct.

The solution presented to the problem of integration tests was to isolate the service or entity being tested via interfaces and use mock objects to allow the class under test to be tested without bringing in the dependencies of other concrete classes. Once these dependencies are broken and you’re dealing with a single concrete object, the test is no longer an integration test but an isolated object test, or focused test.

Joe challenged the audience to write our tests using the single assert per test principle for 3 months. He wasn’t presenting the principle as the correct way to write tests, only that after 3 months of writing the tests as such, we would learn how to write better tests.

Joe also presented on the idea of Contract Testing, where you create a super test fixture class that tests the behavior of an interface and then create sub test fixture classes for all of the classes that implement that interface.

I was quite disappointed in how the talk turned into a unit testing practices session. Unfortunately this only became apparent around 45 minutes into the session and it was too late to change. It could have been a better session if it was more targeted as a way to improve monolithic and highly coupled unit tests and billed as such.

Before the session had started, Joe was talking about talking in E-Prime. E-Prime is a subset of the English language that does not use any form of the verb to be. He presented it as a way to be, or to project as being less judgmental. It sounds like an interesting exercise and something to investigate.

Swag

A drink bottle, Becoming Agile in an imperfect world by Greg Smith and Ahmed Sidky, Agile 2009 Conference book, Lean-Agile Pocket Guide for Scrum Teams by Alan Shalloway and James R. Trott Real Options at Agile 2009 comic and a bunch of useless advertising.

I’m assuming you’ve read my previous post on Setting up a Git server with Windows Server 2008 and are ready to follow along as the steps assume you’ve already installed Cygwin with Git, OpenSSH and Python.

The blog post by Sandesh Singh on setting up Gitosis with Windows Vista was an amazing resource and without it, I would still be trying to get Gitosis working.

Installing Python Setuptools

• Download the Python Setuptools egg.
• Open a Cygwin bash prompt and navigate to the directory containing your download.
• Execute

  sh setuptools-0.6c9-py2.5.egg

• You should see

  Processing setuptools-0.6c9-py2.5.egg
  Copying setuptools-0.6c9-py2.5.egg to /usr/lib/python2.5/site-packages
  Adding setuptools 0.6c9 to easy-install.pth file
  Installing easy_install script to /usr/bin
  Installing easy_install-2.5 script to /usr/bin
  
  Installed /usr/lib/python2.5/site-packages/setuptools-0.6c9-py2.5.egg
  Processing dependencies for setuptools==0.6c9
  Finished processing dependencies for setuptools==0.6c9
  

• Execute

  chmod +r /usr/lib/python2.5/ -R

Installing Gitosis

• Download or clone the Gitosis repository
• Open a Cygwin bash prompt and navigate to the directory containing Gitosis.
• Execute

  python setup.py install

• Copy the public key of the user you wish to administer the Gitosis server to /tmp directory.
• Log out of the Administrator account and login as the git account.
• Open a Cygwin bash prompt and execute

  gitosis-init < /tmp/id_rsa.pub

• You should see

  Initialized empty Git repository in /home/git/repositories/gitosis-admin.git/
  Reinitialized existing Git repository in /home/git/repositories/gitosis-admin.git/
  

• Execute

  chmod 755 /home/git/repositories/gitosis-admin.git/hooks/post-update

Gitosis is now setup and we're ready to clone the gitosis-admin repository to create and administer Git repositories on our server.

The server operating system we’re running is Windows Server 2008.

What is Git?

Git is a distributed version control system originally developed by Linus Torvalds to manage the Linux kernel.

Git is available on Windows using Cygwin or msysGit.

For the server installation, I’ve chosen to use the Cygwin version of Git. We will be using a SSH server for our server to authenticate users and allow access to the repositories. Using Cygwin will allow us to use the Cygwin version OpenSSH for our server.

Installing Cygwin

• Create the C:\Cygwin directory.
• Create the C:\Cygwin\packages directory.
• Modify the permissions on the C:\Cygwin directory to grant the USERS group modify permissions.
• Download the Cygwin setup package into the C:\Cygwin directory and run the setup.
• Use the following options for the Cygwin setup package:
  • Choose Installation Type
    • Leave default Install from Internet
  • Choose Installation Directory
    • Leave default root directory C:\Cygwin
    • Leave default install for All Users
    • Leave default text file type Unix/binary
  • Select Local Packages Directory
    • Change local packages directory to C:\Cygwin\packages
  • Select Connection Type
    • Leave default direct connection
  • Choose Download Site(s)
    • Add a local mirror
  • Select Packages
    • Select Devel > git
    • Select Devel > git-completion
    • Select Devel > git-gui
    • Select Devel > gitk
    • Select Net > openssh
    • Select Python > python
  • Installation Status and Create Icons
    • Leave default create icon on Desktop
    • Leave default Add icon to Start Menu
• Modify the C:\Cygwin\cygwin.bat file to set the CYGWIN environment variable. The whole file should appear as follows:

  @echo off
  set CYGWIN=binmode tty ntsec
  
  c:
  chdir c:\cygwin\bin
  
  bash --login -i

• Run Cygwin from the desktop. It should display:

  Copying skeleton files.
  These files are for the user to personalise
  their cygwin experience.
  
  These will never be overwritten.
  
  './.bashrc' -> '/home/Administrator//.bashrc'
  './.bash_profile' -> '/home/Administrator//.bash_profile'
  './.inputrc' -> '/home/Administrator//.inputrc'

• Execute

  mount -s --change-cygdrive-prefix /
  

• Execute

  mkdir -p /home
  

• Execute

  chmod +r //etc//passwd
  chmod +r //etc//group
  chmod 755 //var
  

  Note: The above statements should use a single slash rather than a double slash. The double slash is required to work around the filter from my blogging software.

• Close the Cygwin bash prompt

Installing OpenSSH

• Open the Cygwin bash prompt as an Administrator via right clicking and selecting Run as administrator.
• Execute

  ssh-host-config

• You should see

  *** Info: Generating /etc/ssh_host_key
  *** Info: Generating /etc/ssh_host_rsa_key
  *** Info: Generating /etc/ssh_host_dsa_key
  *** Info: Creating default /etc/ssh_config file
  *** Info: Creating default /etc/sshd_config file
  *** Info: Privilege separation is set to yes by default since OpenSSH 3.3.
  *** Info: However, this requires a non-privileged account called 'sshd'.
  *** Info: For more info on privilege separation read /usr/share/doc/openssh/README.privsep.
  *** Query: Should privilege separation be used? (yes/no)
  

• Type

  yes
  

• You should see

  *** Info: Note that creating a new user requires that the current account have
  *** Info: Administrator privileges.  Should this script attempt to create a
  *** Query: new local account 'sshd'? (yes/no)
  

• Type

  yes
  

• You should see

  *** Info: Updating /etc/sshd_config file
  
  *** Warning: The following functions require administrator privileges!
  
  *** Query: Do you want to install sshd as a service?
  *** Query: (Say "no" if it is already installed as a service) (yes/no)
  

• Type

  yes
  

• You should see

  *** Info: Note that the CYGWIN variable must contain at least "ntsec"
  *** Info: for sshd to be able to change user context without password.
  *** Query: Enter the value of CYGWIN for the daemon: [ntsec]
  

• Type

  binmode tty ntsec
  

• You should see

  *** Info: On Windows Server 2003, Windows Vista, and above, the
  *** Info: SYSTEM account cannot setuid to other users -- a capability
  *** Info: sshd requires.  You need to have or to create a privileged
  *** Info: account.  This script will help you do so.
  
  *** Info: You appear to be running Windows 2003 Server or later.  On 2003
  *** Info: and later systems, it's not possible to use the LocalSystem
  *** Info: account for services that can change the user id without an
  *** Info: explicit password (such as passwordless logins [e.g. public key
  *** Info: authentication] via sshd).
  
  *** Info: If you want to enable that functionality, it's required to create
  *** Info: a new account with special privileges (unless a similar account
  *** Info: already exists). This account is then used to run these special
  *** Info: servers.
  
  *** Info: Note that creating a new user requires that the current account
  *** Info: have Administrator privileges itself.
  
  *** Info: No privileged account could be found.
  
  *** Info: This script plans to use 'cyg_server'.
  *** Info: 'cyg_server' will only be used by registered services.
  *** Query: Do you want to use a different name? (yes/no)
  

• Type

  no
  

• You should see

  *** Query: Create new privileged user account 'cyg_server'? (yes/no)
  

• Type

  yes
  

• You should see

  *** Info: Please enter a password for new user cyg_server.  Please be sure
  *** Info: that this password matches the password rules given on your system.
  *** Info: Entering no password will exit the configuration.
  *** Query: Please enter the password:
  

• Type and confirm a password for the new ‘cyg_server’ account.
• After confirming the password, you should see

  *** Info: User 'cyg_server' has been created with password 'azxggsri7#35z'.
  *** Info: If you change the password, please remember also to change the
  *** Info: password for the installed services which use (or will soon use)
  *** Info: the 'cyg_server' account.
  
  *** Info: Also keep in mind that the user 'cyg_server' needs read permissions
  *** Info: on all users' relevant files for the services running as 'cyg_server'.
  
  *** Info: In particular, for the sshd server all users' .ssh/authorized_keys
  *** Info: files must have appropriate permissions to allow public key
  *** Info: authentication. (Re-)running ssh-user-config for each user will set
  *** Info: these permissions corrently. [Similary restrictions apply, for
  *** Info: instance, for .rhosts files if the rshd server is running, etc].
  
  *** Info: The sshd service has been installed under the 'cyg_server'
  *** Info: account.  To start the service now, call `net start sshd' or
  *** Info: `cygrunsrv -S sshd'.  Otherwise, it will start automatically
  *** Info: after the next reboot.
  
  *** Info: Host configuration finished. Have fun!
  

• Execute

  net start sshd

• Open the Windows Firewall Editor and create an exception to allow TCP traffic on port 22.

Creating a Git user account for SSH access

Single SSH account will run under.

• Create a ‘git’ account via the standard windows tools and make sure to disable password expiry.
  The account should be a member of the USERS group.
• Open the Cygwin bash prompt and type

  mkpasswd -l -u git -p //home >> //etc//passwd

  Note: The above statements should use a single slash rather than a double slash. The double slash is required to work around the filter from my blogging software.

• Log out of the Administrator account and login as the git account.
• Run Cygwin from the desktop. It should display:

  Copying skeleton files.
  These files are for the user to personalise
  their cygwin experience.
  
  These will never be overwritten.
  
  './.bashrc' -> '/home/git//.bashrc'
  './.bash_profile' -> '/home/git//.bash_profile'
  './.inputrc' -> '/home/git//.inputrc'

• Execute

  ssh-user-config

• You should see

  *** Warning: group and other have been revoked write permission to your home
  *** Warning: directory /home/git.
  *** Warning: This is required by OpenSSH to allow public key authentication using
  *** Warning: the key files stored in your .ssh subdirectory.
  *** Warning: Revert this change ONLY if you know what you are doing!
  
  *** Query: Shall I create an SSH1 RSA identity file for you? (yes/no)
  

• Type

  no

• You should see

  *** Query: Shall I create an SSH2 RSA identity file for you? (yes/no)

• Type

  yes

• You should see

  *** Info: Generating /home/git/.ssh/id_rsa
  Enter passphrase (empty for no passphrase):
  

• Press enter to create with an empty passphrase and press enter again to confirm.
• You should see

  *** Query: Do you want to use this identity to login to this machine? (yes/no)
  

• Type

  yes

• You should see

  *** Info: Adding to /home/git/.ssh/authorized_keys
  *** Query: Shall I create an SSH2 DSA identity file for you? (yes/no)
  

• Type

  no

• You should see

  *** Info: Configuration finished. Have fun!

We have now configured our Windows Server 2008 machine with Git and an account to use with SSH access. In the next blog post, I’ll cover installation and configuration of Gitosis to secure access and authentication of repositories.

If the Interface Segregation Principle is less relevant for dynamic languages, does that mean SOLID => SOLD for dynamic languages? :P

Shannon’s shared items

A couple of themes came out in the talk, being that scalable parallel programs will continue to see improvements, but single threaded software will not. Microsoft is moving away from a thread based model and more towards a task based model. Tasks are a more generic term for a unit of work which is more closely aligned with the problem domain. Another focus is on scalable data structures.

Stephen Toub presented on current ways to do concurrent programming in .NET using the existing frameworks.

• System.Threading.Thread
• System.Threading.ThreadPool
• Asynchronous delegate invocation
• Asynchronous Programming Model

An interesting item of note that using the ThreadPool to execute a delegate was faster than asynchronous delegate invocation, as the delegate invocation involves the remoting stack and then ends up using the ThreadPool anyway.

Manual thread management (calling Thread.Interupt, Thread.Abort, Thread.Pause & Thread.Resume) was extremely discouraged. So much so, there was talk about these APIs being deprecated in a future version of the CLR.

• Interupt only interupts a thread in a wait/sleep or join cycle. Calling this method will throw a ThreadInterruptException
• Abort will abort a thread at any moment (except during PInvoke) and will throw a ThreadAbortException. This exception is special cased by the runtime to rethrow this exception if you have caught it.
• Suspend/Resume will suspend the thread at any point, including inside a lock.

In .NET, when you lock on an object, information is stored in the available memory associated with the object. The reason this is interesting is because this additional memory allows the CLR to take a ‘slim’ lock rather than a ‘fat’ lock. However, if you call GetHashCode on this object (unless you have overridden the base implementation), this memory is used to store hash code information, and any locks on this object will be ‘fat’ locks.

Another interesting item is that items marked ThreadStatic will only be run once (not once per thread as you might assume). What this means is that if thread 1 loads up a class with a static field marked as ThreadStatic, it will have the expected value. If thread 2 then loads up this class, the static field will be null.

Joe Duffy gave a very low level talk on concurrency and shared state. It was an extremely interesting talk, about a quarter of which I was able to follow with my brain melting :(. An great example highlighted that on an x86 machine, setting an int64 value is not an atomic operation, and it’s possible for the value to be half set when the thread switches out. Compilers are free to re-order and inline statements, so you might get what you’ve asked for, but not what you’re written, which can have an impact if you’re sharing state across threads.

Synchronization best practices (Stephen Toub)

• Lock consistently
  • Do lock over all mutable shared state
  • Do Always use the same lock for the same state
  • Do comment on how state is protected
• Lock for the right duration
  • Do lock over the entire invariant
  • Don’t lock for longer than is absolutely necessary
• Make critical regions short and sweet
  • Do minimize the time you hold on to a lock
  • Don’t call other’s code while you hold lock
  • Don’t block while you hold lock
• Encapsulate your locks
  • Don’t use public lock objects
  • Don’t lock on Types or Strings
• Avoiding deadlocks
  • Do acquire locks in a consistent order
• Locking Misceallany
  • Do document your locking policy (especially for public APIs)
  • Do use a reader/writer lock if readers are common
  • Do prefer lock based code to lock free code
  • Do prefer monitors over kernel synchronization
  • Avoid lock recursion in your design
  • Don’t build your own locks
  • Avoid writing your own thread pool

So what’s coming in .NET 4.0?

• No real surprise, PLINQ and the Task Parallel Library (currently available in the Parallel Extensions CTP) will be included.
• A Concurrency Runtime, consisting of an improved ThreadPool with a work stealing algorith, A new task scheduler and a resource manager.
• Improved tooling support with parallel debugger windows and profiler concurrency analysis.
• Data structures such as thread safe collections ConcurrentStack<T>, ConcurrentQueue<T> and ConcurrentDictionary<K,V>. Work exchange structures such as BlockingCollection<T> and new locks such as ManualResetEventSlim<T> and SemaphoneSlim<T>.

Concurrent Programming on Windows by Joe Duffy
It looks like the trend continues, I managed to win something by sticking my hands up and answering a quiz question :) I scored the first copy to be given away of Joe Duffy’s new Concurrent Programming book. This adds to the impressive list of list of things I’ve won at nerd events.

It’s hot.

After an expensive taxi ride from LAX, I arrive at the hotel to find Scott Guthrie hacking away on his laptop in the lobby.

At the reception, they inform me that they need my credit card, which they scan, then decline. Apparently when you book a room they don’t charge the room, they wait until you get here and here I am without a corporate credit card or a room. 5 dollars, 5 minutes of internet usage later I’m back at reception, cashed up and manage to get into my room.

I manage to get in contact with Alex and we head out to Santa Monica Pier and the beach. We took some really cool photos and had the eerie experience of being familiar with a place you’ve never been too before…

Next up tomorrow is the pre conference…