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. WaitForSingleObject() Problem

WaitForSingleObject() Problem

Scheduled Pinned Locked Moved C / C++ / MFC
help
7 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.
  • L Offline
    L Offline
    lisoft
    wrote on last edited by
    #1

    There are two threads: //thread_one: { HANDLE hEvent=CreateEvent(NULL,TRUE,FALSE,NULL); SetEvent(hEvent); // do sth // ... AfxBeginThread(thread_two,this); WaitForSingleObject(hEvent,INFINITE); // continue to do sth... } thread_two: { ResetEvent(hEvent); // do sth // ... SetEvent(hEvent); } I want thread_one to wait at WaitForSingleObject until thread_two passing SetEvent. But the fact is thread_one wait at WaitForSingleObject for ever!!

    R A 2 Replies Last reply
    0
    • L lisoft

      There are two threads: //thread_one: { HANDLE hEvent=CreateEvent(NULL,TRUE,FALSE,NULL); SetEvent(hEvent); // do sth // ... AfxBeginThread(thread_two,this); WaitForSingleObject(hEvent,INFINITE); // continue to do sth... } thread_two: { ResetEvent(hEvent); // do sth // ... SetEvent(hEvent); } I want thread_one to wait at WaitForSingleObject until thread_two passing SetEvent. But the fact is thread_one wait at WaitForSingleObject for ever!!

      R Offline
      R Offline
      Robert Bielik
      wrote on last edited by
      #2

      After CreateEvent the only place you need to do anything with the event is at the end of thread_two. Remove the SetEvent in thread_one and ResetEvent in thread_two. Also make sure that the SetEvent in thread_two really sets the event that the WaitForSingleObject is waiting for. Mind local variable scope. I.e. if you have and event handle in your class called hEvent, and you do: HANDLE hEvent = ::CreateEvent(NULL, TRUE, FALSE, NULL); the class (or object really) hEvent (having the same name as above) will not be set and the WaitForSingleObject will wait for a non-initialized event, thus holding execution indefinitely. Hope this helps.

      L 1 Reply Last reply
      0
      • L lisoft

        There are two threads: //thread_one: { HANDLE hEvent=CreateEvent(NULL,TRUE,FALSE,NULL); SetEvent(hEvent); // do sth // ... AfxBeginThread(thread_two,this); WaitForSingleObject(hEvent,INFINITE); // continue to do sth... } thread_two: { ResetEvent(hEvent); // do sth // ... SetEvent(hEvent); } I want thread_one to wait at WaitForSingleObject until thread_two passing SetEvent. But the fact is thread_one wait at WaitForSingleObject for ever!!

        A Offline
        A Offline
        Aamir Butt
        wrote on last edited by
        #3

        Your hEvent in Thread one is a local variable which never gets set. Make it a class member or a global variable and then set that global variable from outside thread one.


        Stuck to Programming through an unbreakable bond :( My Articles


        1 Reply Last reply
        0
        • R Robert Bielik

          After CreateEvent the only place you need to do anything with the event is at the end of thread_two. Remove the SetEvent in thread_one and ResetEvent in thread_two. Also make sure that the SetEvent in thread_two really sets the event that the WaitForSingleObject is waiting for. Mind local variable scope. I.e. if you have and event handle in your class called hEvent, and you do: HANDLE hEvent = ::CreateEvent(NULL, TRUE, FALSE, NULL); the class (or object really) hEvent (having the same name as above) will not be set and the WaitForSingleObject will wait for a non-initialized event, thus holding execution indefinitely. Hope this helps.

          L Offline
          L Offline
          lisoft
          wrote on last edited by
          #4

          The reason I call ReSetEvent is that WaitForSingleObject at thread_one is not always waiting for when thread_two sets the event, so I set the event to nonsignaled state by using ReSetEvent to make sure thread_one should wait at WaitForSingleObject when thread_two is running. What's wrong with the ReSetEvent function I called could cause 'waiting for ever' ? BTW. Assume there is no variable scope problem. Thanks

          R 1 Reply Last reply
          0
          • L lisoft

            The reason I call ReSetEvent is that WaitForSingleObject at thread_one is not always waiting for when thread_two sets the event, so I set the event to nonsignaled state by using ReSetEvent to make sure thread_one should wait at WaitForSingleObject when thread_two is running. What's wrong with the ReSetEvent function I called could cause 'waiting for ever' ? BTW. Assume there is no variable scope problem. Thanks

            R Offline
            R Offline
            Robert Bielik
            wrote on last edited by
            #5

            Theres no problem per se. But the first reason thread_one is not waiting is because of the SetEvent (after the CreateEvent method). This means that when you get to the WaitForSingleObject, it will just continue right on. So as I said, you should remove it. The second reason is multithreading. When you start thread_two, don't assume that the ResetEvent in thread_two will get executed before you get to the WaitForSingleObject in thread_one (it is less probable than not that that will ever happen). So this is why thread_one does not wait sometimes, all at the mercy of Windows thread scheduling. So, remove the SetEvent in thread_one and the ResetEvent in thread_two (optionally of course, because it doesn't do anything) and the code as it stands should work A OK.

            L 1 Reply Last reply
            0
            • R Robert Bielik

              Theres no problem per se. But the first reason thread_one is not waiting is because of the SetEvent (after the CreateEvent method). This means that when you get to the WaitForSingleObject, it will just continue right on. So as I said, you should remove it. The second reason is multithreading. When you start thread_two, don't assume that the ResetEvent in thread_two will get executed before you get to the WaitForSingleObject in thread_one (it is less probable than not that that will ever happen). So this is why thread_one does not wait sometimes, all at the mercy of Windows thread scheduling. So, remove the SetEvent in thread_one and the ResetEvent in thread_two (optionally of course, because it doesn't do anything) and the code as it stands should work A OK.

              L Offline
              L Offline
              lisoft
              wrote on last edited by
              #6

              Thanks for help. But I found sth strange. When thread_one is waiting at WaitForSingleObject() and at the same time thread_two was also suspended instead of running as I supposed before. I use a counter in thread_two to caculated how many steps passed by when thread_one is waiting for it, but the fact is that the counter remains the same between WaitForSingleObject(hEvent,1000); that is to say thread_two was suspended when thread_one call WaitForSingleObject, but why????:(

              R 1 Reply Last reply
              0
              • L lisoft

                Thanks for help. But I found sth strange. When thread_one is waiting at WaitForSingleObject() and at the same time thread_two was also suspended instead of running as I supposed before. I use a counter in thread_two to caculated how many steps passed by when thread_one is waiting for it, but the fact is that the counter remains the same between WaitForSingleObject(hEvent,1000); that is to say thread_two was suspended when thread_one call WaitForSingleObject, but why????:(

                R Offline
                R Offline
                Robert Bielik
                wrote on last edited by
                #7

                That does indeed sound strange. Are you linking with the multithreaded runtime libraries? Because that kind of odd behavior could arise from linking with the single threaded ones.

                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