I don't know. The best answer I can give is: write it to not "know" about the number of processors. This is the simplest code you could write: you're going to let the OS do all the scheduling work. After all the OS is going to be context-switching under you anyway to service the network, do file IO, do whatever. If the performance isn't all it's cracked up to be, now add some moderately complex code to identify how many processors there are, how to split up the total work between processors, etc. Run it and profile. Tweak. Run it and profile. Rinse and repeat. I would doubt that you'd make much difference for the amount of work it will take you. I would hazard a guess that improving the algorithm that's doing the work will get you more bang for your coding buck. The threadpool is designed to obviate the need to continually create OS threads, an expensive process. That's all. It makes no difference to the speed of execution of code in the thread. References, wow. Not off the top of my head, no, sorry. Certainly I don't know of any in the C#/.NET world. Cheers, Julian Program Manager, C# This posting is provided "AS IS" with no warranties, and confers no rights.
