What is this race condition that the OpenMutex documentation is trying to warn me about?


A customer asked for clarification on what they considered an enigmatic sentence in the documentation for the Open­Mutex function:

If your multithreaded application must repeatedly create, open, and close a named mutex object, a race condition can occur. In this situation, it is better to use Create­Mutex instead of Open­Mutex, because Create­Mutex opens a mutex if it exists and creates it if it does not.

"What is this race condition the documentation is talking about? Our program uses Open­Mutex and we are wondering if we should switch to Create­Mutex."

Consider two threads. One thread calls Create­Mutex, then Close­Handle, then Create­Mutex, then Close­Handle, then Create­Mutex, then Close­Handle, and so on.

The other thread calls Open­Mutex.

The race condition is that the second thread's call to Open­Mutex will fail if it takes place after the first thread calls Close­Handle and before it gets to make its next call to Create­Mutex.

One of my colleagues couldn't understand why MSDN bothers to say anything about this situation at all. "You can't open a mutex that doesn't exist. Duh. I think this adds more confusion than it helps."

I suspect the reason why MSDN bothers to say anything about this is that there was a customer who had two threads. One thread calls Create­Mutex, then Close­Handle, then Create­Mutex, then Close­Handle, then Create­Mutex, then Close­Handle, and so on. The other thread calls Open­Mutex.

This customer found that if the second thread calls Open­Mutex at an inopportune time, the call fails. They then insisted that something be added to the documentation to state explicitly that a bad idea is a bad idea. Probably because they needed something in writing to show their management in order to justify the time they are going to need to spend fixing the bug.

Once again, MSDN has been forced into being a pawn in some company's internal politics.

Comments (12)
  1. Rutger says:

    They then insisted that something be added to the documentation to state explicitly that a bad idea is a bad idea. Probably because they needed something in writing to show their management in order to justify the time they are going to need to spend fixing the bug.

    I hate those… I really hate those. Have I mentioned already how I hate those if not I really really hate those issues that are there because the people further down the line are incapable of explaining how things work to their customer/manager

    1. alegr1 says:

      “I have people skills! What’s wrong with you, people?”

    2. smf says:

      If the customer/manager is the type of person who trust a stranger third party over the person they have employed to do the work, then there is no hope of explaining anything to them.

      The only thing you can blame the people further down the line for is continuing to work there.

    3. It reminds me of the times I have had to argue with clients or partners about their implementation of a specification that were were all supposed to adhere to. These scenarios were all too common:

      “Do A, then B, then C” -> It doesn’t explicitly say you CAN’T do A, X, Y, Z, then B and C”
      “RFU” -> Used for some proprietary value
      “Can be either A or B” -> Competitor uses A, so we’re going to use B!
      “Can be either A or B” -> Competitor uses A, different competitor uses B so we’re going to do A when we feel like it and B when we feel like it, but you must be clairvoyant to know when and where
      “Optional” -> Mandatory
      “Mandatory” -> Optional
      “Conditional” -> ????
      “Deprecated” -> Mandatory
      “Do not use” -> Use

      …and so on.

    4. cheong00 says:

      > Have I mentioned already how I hate those if not I really really hate those issues that are there because the people further down the line are incapable of explaining how things work to their customer/manager

      Sometimes it’s not even about whether those does the line are capable of explaining it or not, it’s just the upper management won’t hear, thus need documentation from technology vendor to support the need to fix a bug (that may not be reproduciable by QA)

      To them, a bug not reported is not a bug that exist, unless there are other source say there is really a potential bug there.

  2. WvR says:

    If you handle a mutex in a way that requires a mutex to regulate the mutex, it will require an additional mutex to regulate the mutex.
    It’s turtles all the way down.

  3. Yukkuri says:

    Maybe MS should just make a bunch of coupons to send out to people when this sort of thing comes in, like thus: https://www.gtown.com/coupons/57620

  4. mikeb says:

    FWIW, I don’t find the enigmatic sentence to be confusing at all.

  5. Karellen says:

    Yo dawg, I heard you like race-free code, so I put a mutex in your mutex, so you can synchronise while you synchronise!

    1. Karellen says:

      Darnit! That was meant to be a reply to WvR

      1. WvR says:

        Don’t forget to regulate that last synchronization!

  6. Ray Koopa says:

    Oh how I wish your linked TechNet article would not have come out translated into German automatically… it was horrible! (At least it didn’t try to translate your first name with “Strahl-Himmelskörper” or anything…)

Comments are closed.

Skip to main content