Because of the need to process large numbers of tests within the shortest possible space of time, NCrunch supports the ability to run tests concurrently in separate processes.
Note that NCrunch will never run tests concurrently within the same process - so you don't need to be concerned about concurrent access to static members, etc.
Many tests make use of resources outside of the test process (i.e. the file system), and therefore not all tests will immediately support being run concurrently. To prevent these tests from raising alarms while you get to grips with NCrunch, parallel execution is turned off by default. It can be turned on at global level by adjusting the Max Number Of Processing Threads global configuration to a value higher than 1, and at solution level by adjusting the Allow Parallel Test Execution solution configuration option to true.
Adjusting the number of tasks to run concurrently often involves some consideration and a little trial and error. Setting a high number will increase the background system load and may cause your system to start running slowly. The best setting is usually equal to the number of processor cores you have assigned to NCrunch. You can control which processor cores you wish NCrunch to use by adjusting the CPU Cores Assigned To configuration options. For more information, see performance tuning.
Parallel execution can be hugely advantageous as it gives the engine more flexibility to better manage the test pipeline. It can improve the feedback times on short running tests - as more resources are available to pick up the work when required.
It's fairly normal that there will be tests in your solution that won't like being run in parallel. These can often be large resource-intensive integration tests that may use exclusive areas of the file system or a database. You should make sure you decorate these with the ExclusivelyUsesAttribute and/or the InclusivelyUsesAttribute.