High CPU usage with multiple distributor threads and empty storage queue.

Here's a patch for the problem we saw with the distributor running with multiple threads against a storage queue that's empty (because workers are all busy) I was mistaken about it being an issue with Receive when I was trying to remember at NSBCon. The problem lied with the lock used in NextAvailableWorker. Basically one distributor thread is blocked waiting on Receive (inside the critical section protected by the lock) but other workers will spin as they continually reach the TryEnter.

I noticed that there's a branch for moving away from the distributor's storage queue, and so that will likely eliminate this problem in future versions.