title: Why WaitForMultipleObjectsEx acquires mutex during APC?
body: <p>I have 5 threads (on a multicore system) that simultaneously wait for:</p>
  
  <ol>
  <li>A mutex M to be acquired</li>
  <li>An event E to be signaled</li>
  </ol>
  
  <p>I'm using <code>WaitForMultipleObjectsEx(..., TRUE, INFINITE, TRUE)</code> since the threads use APCs.<br>
  Note that the APCs do <em>not</em> use/touch/alter/observe the mutex or the event in any way.</p>
  
  <p>I'm using Visual Studio along with <a href="http://processhacker.sourceforge.net/" rel="nofollow">Process Hacker</a> to debug, and I'm witnessing a strange phenomenon:<br>
  Frequently, the thread that is <em>supposed</em> to run (call it thread A) is still waiting on the two objects.  </p>
  
  <p>I say "supposed to run" because:</p>
  
  <ol>
  <li>I have verified many times (including via Process Hacker) that the E is indeed in a signaled state  </li>
  <li>No other thread has acquired ownership of M.  In fact, <em>3</em> other threads are <em>also</em> waiting to acquire M.</li>
  </ol>
  
  <p>Nevertheless, according to Process Hacker (which uses <a href="http://forum.sysinternals.com/check-mutant-state-without-altering-its-state_topic27466.html" rel="nofollow"><code>NtQueryMutant</code> to retrieve the count</a>), <em>during such scenarios</em>, M has an absurdly low "Count" value, such as -618.</p>
  
  <p>Of course, I'm not forgetting to call <code>ReleaseMutex</code> (yes, I'm checking the return value too); indeed, once someone later acquires the mutex, the Count increases back up.</p>
  
  <p>So this begs the question: if 3 of the 4 other threads are sleeping, what is the last thread (B) doing?  </p>
  
  <p>The answer is that B is <strong>executing an APC</strong> inside the <code>WaitForMultipleObjectsEx</code> call.<br>
  <em>No matter how far I "step" through B</em> in Visual Studio (even all the way back up <code>RtlDispatchAPC</code>), <strong>none</strong> of the other threads wake up.<br>
  It is only <em>after</em> that APC has finished executing that any thread wakes up!</p>
  
  <p>I find this quite bizarre, <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/ms687028.aspx" rel="nofollow"><code>WaitForMultipleObjectEx</code>'s documentation says</a>:</p>
  
  <blockquote>
    <p>When <code>bWaitAll</code> is <code>TRUE</code>, the function's wait operation is completed only when the states of all objects have been set to signaled. <strong>The function does not modify the states of the specified objects until the states of all objects have been set to signaled.</strong> For example, a mutex can be signaled, but <strong>the thread does not get ownership</strong> until the states of the other objects are also set to signaled. In the meantime, some other thread may get ownership of the mutex, thereby setting its state to nonsignaled.</p>
  </blockquote>
  
  <p>Is the documentation wrong, or is this a mistake on my part?</p>
  
  <p>Why does <code>WaitForMultipleObjectsEx</code> acquire the mutex during the execution of an APC, even though it <em>knows</em> it will never acquire the mutex anyway (because executing an APC implies it will return <code>WAIT_IO_COMPLETE</code>, never acquiring the mutex)?</p>