CloseHandle vs. ReleaseMutex

Given that Win32 mutexes are "abandoned" when the owning thread exits without releasing them, you might make the mistake of assuming that closing a mutex handle without releasing it would have the same effect, but you'd be wrong. Suppose the following sequence of events:

1. Process PA creates and owns named mutex M.
2. Process PB "creates" a mutex by the same name. (GetLastError returns ERROR_ALREADY_EXISTS, so PB knows it didn't really create M, but that's beyond the scope of this discussion.)
3. PA has done whatever it needed to, decides it is done with M, and closes its handle to M. M still exists, of course, because PB still has a handle to it. But M has just entered a "limbo" state in which it's useless to everyone and everything.
4. PB attempts to "own" the mutex by passing it to WaitForSingleObject, and let's suppose for the sake of discussion that PB passes an INFINITE time-out to WaitForSingleObject.

Here's an alternate sequence of events:

1. Process PA creates and owns named mutex M.
2. Process PB "creates" a mutex by the same name. (GetLastError returns ERROR_ALREADY_EXISTS, so PB knows it didn't really create M, but that's beyond the scope of this discussion.)
3. PB attempts to "own" the mutex by passing it to WaitForSingleObject, and let's suppose for the sake of discussion that PB passes an INFINITE time-out to WaitForSingleObject.
4. PA has done whatever it needed to, decides it is done with M, and closes its handle to M. M still exists, of course, because PB still has a handle to it. But M has just entered a "limbo" state in which it's useless to everyone and everything.

In both sequences, PB is now stuck; WaitForSingleObject will never return. The only difference is that I expected PB to block in the second sequence after step 3 but then unblock after step 4. It's possible PA could "create" another handle to the mutex and pass the handle to ReleaseMutex, and I didn't try that, but it would be consistent with the notion that CloseHandle closes a handle to the mutex object, which exists in the kernel independently of the handle. Still, PA "creating" the handle again would be weird, and I expected CloseHandle to have the same effect as PA exiting, which was wrong.