Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. C / C++ / MFC
  4. Mutex WaitForSingleObject does not Signal

Mutex WaitForSingleObject does not Signal

Scheduled Pinned Locked Moved C / C++ / MFC
visual-studiodebugging
11 Posts 3 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • F ForNow

    I piece of code that is executed by 4 threads. I want to Serialize it one at a time So I Create a Mutex handle = CreateMutex(NULL,FALSE,NULL); I observe that the HANDLE its not NULL Then I "dwWaitResult = WaitForSingleObject(sysblk.single_thread,INFINITE)" (I am running this under VS debugger and have a few breakpoints before I do the ReleaseMutex) Then finally the first thread gets to the end of the serialized code. I do a "ReleaseMutex(sysblk.single_thread)" it returns 1 however When I look back at the VS Threads Window and click on each the 3 threads there is an inverted arrow at the WaitForSingleObject indicating that none of the threads were signaled Thanks

    L Offline
    L Offline
    Lost User
    wrote on last edited by
    #2

    What is sysblk.single_thread in the above? You should be waiting on and releasing the Mutex handle, as described at Using Mutex Objects (Windows)[^].

    F 1 Reply Last reply
    0
    • L Lost User

      What is sysblk.single_thread in the above? You should be waiting on and releasing the Mutex handle, as described at Using Mutex Objects (Windows)[^].

      F Offline
      F Offline
      ForNow
      wrote on last edited by
      #3

      Sorry that was a typo as I typed the code and didn't cut paste it was meant to be WaitForSingleObject(handle,INFINITE); and ReleaseMutex(handle); Let me ask question after the first thread goes thru the WaiForSingleObject it turns from signaled to non-signaled then if more then one thread is waitting when the ReleaseMutex is executed it lets only ONE thread at a time to process while the other remain waiting till the next ReleaseMutex correct ?

      L 1 Reply Last reply
      0
      • F ForNow

        Sorry that was a typo as I typed the code and didn't cut paste it was meant to be WaitForSingleObject(handle,INFINITE); and ReleaseMutex(handle); Let me ask question after the first thread goes thru the WaiForSingleObject it turns from signaled to non-signaled then if more then one thread is waitting when the ReleaseMutex is executed it lets only ONE thread at a time to process while the other remain waiting till the next ReleaseMutex correct ?

        L Offline
        L Offline
        Lost User
        wrote on last edited by
        #4

        That should be the way is works. Each thread should acquire the Mutex (i.e. lock it) in order to protect the data. When they finish the critical section they should Release it. The point being that you only want one thread through this path at any one time.

        F 1 Reply Last reply
        0
        • F ForNow

          I piece of code that is executed by 4 threads. I want to Serialize it one at a time So I Create a Mutex handle = CreateMutex(NULL,FALSE,NULL); I observe that the HANDLE its not NULL Then I "dwWaitResult = WaitForSingleObject(sysblk.single_thread,INFINITE)" (I am running this under VS debugger and have a few breakpoints before I do the ReleaseMutex) Then finally the first thread gets to the end of the serialized code. I do a "ReleaseMutex(sysblk.single_thread)" it returns 1 however When I look back at the VS Threads Window and click on each the 3 threads there is an inverted arrow at the WaitForSingleObject indicating that none of the threads were signaled Thanks

          M Offline
          M Offline
          Munchies_Matt
          wrote on last edited by
          #5

          Take a look at Using Mutex Objects (Windows)[^] The mutex isn't acquired by creating it, it is acquired by successfully waiting on it.

          F 1 Reply Last reply
          0
          • M Munchies_Matt

            Take a look at Using Mutex Objects (Windows)[^] The mutex isn't acquired by creating it, it is acquired by successfully waiting on it.

            F Offline
            F Offline
            ForNow
            wrote on last edited by
            #6

            In the Microsoft example there are 2 threads so .. 1) thread gains ownership of the signaled object and the second waits In may case they are 4 so If thread 1 gains ownership do threads 2 - 4 waits if so When the ReleaseMutex are all released or only one at a time if so Which one

            M 1 Reply Last reply
            0
            • L Lost User

              That should be the way is works. Each thread should acquire the Mutex (i.e. lock it) in order to protect the data. When they finish the critical section they should Release it. The point being that you only want one thread through this path at any one time.

              F Offline
              F Offline
              ForNow
              wrote on last edited by
              #7

              Sorry for the delayed response but I have been very busy at work But can Multiple threads wait on the Mutex with the WaitForSingleObject And then which is released with the ReleaseMutex the one waiting the longest

              L 1 Reply Last reply
              0
              • F ForNow

                Sorry for the delayed response but I have been very busy at work But can Multiple threads wait on the Mutex with the WaitForSingleObject And then which is released with the ReleaseMutex the one waiting the longest

                L Offline
                L Offline
                Lost User
                wrote on last edited by
                #8

                I'm not sure, you would need to run some tests to find out. But in a properly designed application it should not matter, mutexes are not supposed to be FIFO queues.

                1 Reply Last reply
                0
                • F ForNow

                  In the Microsoft example there are 2 threads so .. 1) thread gains ownership of the signaled object and the second waits In may case they are 4 so If thread 1 gains ownership do threads 2 - 4 waits if so When the ReleaseMutex are all released or only one at a time if so Which one

                  M Offline
                  M Offline
                  Munchies_Matt
                  wrote on last edited by
                  #9

                  ForNow wrote:

                  do threads 2 - 4 waits

                  Yes.

                  ForNow wrote:

                  When the ReleaseMutex are all released or only one at a time

                  It depends on the scheduler. Thread scheduling is a very interesting topic in OS design, and the rules can vary from platform. But a general rule is that the waiting thread with the highest priority runs. However some OSs throw in a bit of priority inversion on occasion to free up any deadlocks. Within the same priority group you might decide on say, 'last thread run', or 'first thread waiting' to decide which to activate and give the CPU to. A bit like FIFO, LRU LIFO etc, there are a lot of designs. The important point though is that the OS does this for you so no need to worry about it. Use the example from Microsoft and all will be well.

                  F 1 Reply Last reply
                  0
                  • M Munchies_Matt

                    ForNow wrote:

                    do threads 2 - 4 waits

                    Yes.

                    ForNow wrote:

                    When the ReleaseMutex are all released or only one at a time

                    It depends on the scheduler. Thread scheduling is a very interesting topic in OS design, and the rules can vary from platform. But a general rule is that the waiting thread with the highest priority runs. However some OSs throw in a bit of priority inversion on occasion to free up any deadlocks. Within the same priority group you might decide on say, 'last thread run', or 'first thread waiting' to decide which to activate and give the CPU to. A bit like FIFO, LRU LIFO etc, there are a lot of designs. The important point though is that the OS does this for you so no need to worry about it. Use the example from Microsoft and all will be well.

                    F Offline
                    F Offline
                    ForNow
                    wrote on last edited by
                    #10

                    If all the threads are released it is a problem

                    M 1 Reply Last reply
                    0
                    • F ForNow

                      If all the threads are released it is a problem

                      M Offline
                      M Offline
                      Munchies_Matt
                      wrote on last edited by
                      #11

                      they arent, so you are OK.

                      1 Reply Last reply
                      0
                      Reply
                      • Reply as topic
                      Log in to reply
                      • Oldest to Newest
                      • Newest to Oldest
                      • Most Votes


                      • Login

                      • Don't have an account? Register

                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • World
                      • Users
                      • Groups