title: CLR has been unable to transition from COM context
body: <p>This sort of thing is already on Stack Overflow, <a href="https://stackoverflow.com/questions/2747916/the-clr-has-been-unable-to-transition-from-com-context-for-60-seconds">here.</a> However, it doesn't quite fix the problem.</p>
  
  <p>I'm working on a probability simulator that's multi-threaded. Say, I want to figure out the result of one billion "dice rolls." If this runs for > 1 minute, the following message pops up:</p>
  
  <blockquote>
    <p>The CLR has been unable to transition from COM context <code>0x29eac30</code> to COM context <code>0x29eab78</code> for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as <code>CoWaitForMultipleHandles</code>) and routinely pump messages during long running operations.</p>
  </blockquote>
  
  <p>My code includes, for the situation:</p>
  
  <pre><code>bool done = false;
  while (done)
  {
      done = false;
      foreach (WorkerObject w in workers)
      {
          done = done &amp;&amp; w.done;
      }
  }
  </code></pre>
  
  <p>I'm using <code>Task</code> objects for multi-threading, and there is a <code>Task.Wait()</code> method, but this is a thread-blocking operation that does essentially the same thing as this. Using <code>Thread.Sleep(500)</code> in the loop gives the same result.</p>
  
  <p>Now, I've Googled around for how to actually fix this, and, normally, the "fix" is to disable the compiler warning and to just keep going on with it, but how would I <em>actually</em> fix the problem?</p>