title: Parallel.For vs regular threads
body: <p>I'm trying to understand why Parallel.For is able to outperform a number of threads in the following scenario: consider a batch of jobs that can be processed in parallel. While processing these jobs, new work may be added, which then needs to be processed as well. The <code>Parallel.For</code> solution would look as follows:</p>
  
  <pre><code>var jobs = new List&lt;Job&gt; { firstJob };
  int startIdx = 0, endIdx = jobs.Count;
  while (startIdx &lt; endIdx) {
    Parallel.For(startIdx, endIdx, i =&gt; WorkJob(jobs[i]));
    startIdx = endIdx; endIdx = jobs.Count;
  }
  </code></pre>
  
  <p>This means that there are multiple times where the Parallel.For needs to synchronize. Consider a bread-first graph algorithm algorithm; the number of synchronizations would be quite large. Waste of time, no?</p>
  
  <p>Trying the same in the old-fashioned threading approach:</p>
  
  <pre><code>var queue = new ConcurrentQueue&lt;Job&gt; { firstJob };
  var threads = new List&lt;Thread&gt;();
  var waitHandle = new AutoResetEvent(false);
  int numBusy = 0;
  for (int i = 0; i &lt; maxThreads; i++) 
    threads.Add(new Thread(new ThreadStart(delegate {
      while (!queue.IsEmpty || numBusy &gt; 0) {
        if (queue.IsEmpty)
          // numbusy &gt; 0 implies more data may arrive
          waitHandle.WaitOne();
  
        Job job;
        if (queue.TryDequeue(out job)) {
          Interlocked.Increment(ref numBusy);
          WorkJob(job); // WorkJob does a waitHandle.Set() when more work was found
          Interlocked.Decrement(ref numBusy);
        }
      }
      // others are possibly waiting for us to enable more work which won't happen
      waitHandle.Set(); 
  })));
  threads.ForEach(t =&gt; t.Start());
  threads.ForEach(t =&gt; t.Join());
  </code></pre>
  
  <p>The <code>Parallel.For</code> code is of course much cleaner, but what I cannot comprehend, it's even faster as well! Is the task scheduler just that good? The synchronizations were eleminated, there's no busy waiting, yet the threaded approach is consistently slower (for me). What's going on? Can the threading approach be made faster?</p>
  
  <p>Edit: thanks for all the answers, I wish I could pick multiple ones. I chose to go with the one that also shows an actual possible improvement.</p>