-
November 2nd, 2006, 07:15 PM
#1
Proper way to wait for a thread to return.
I need a thread to wait utnil this bool is set to true. This works fine in debug but when i compile it in release it pretty much dies. What is the proper way to do this?
Code:
while(m_rightClickFinished == false)
{
//wait until right click stuff happens in other thread
}
m_rightClickFinished = false;
return true;
-
November 2nd, 2006, 07:29 PM
#2
Re: Proper way to wait for a thread to return.
It looks like you just want to wait for an Event handle instead of polling
for a variable change. I imagine that if the right-click event takes much
time this little loop will suck up a lot of CPU time. Perhaps wait for the
event - the other thread( where the mouse click stuff is happening ) would
call PulseEvent to resurect the waiting thread. And you can do away with
the rightclick==false variable.
-
November 2nd, 2006, 07:45 PM
#3
Re: Proper way to wait for a thread to return.
Well the problem is i have an event both of my threads have to do something in order to respond to the thread. I need the main thread to wait until the 2nd thread finishes responding to the event. So once the 2nd thread is done i just set the bool that lets the first thread know it can go ahead and do it's thing.
Simple enough only in release that while leeps get's optimized out i'm assumeing. Would a sleep statement inside of it work? if so how many ms should i use
-
November 2nd, 2006, 07:58 PM
#4
Re: Proper way to wait for a thread to return.
When I say event, I mean the event created/opened by CreateEvent() and
OpenEvent(), not a GUI event. Which is what you mean by event ?
Don't use Sleep() because you're never guaranteed that the thread won't
resume earlier than you want; too high a wait period will slow the program
down.
Main Thread
1) Create an event handle.
2) Something happens that needs a response
3) Call PulseEvent()
Thread 2
1) WaitForSingleObject on the event handle. CreateEvent() on second event
2) Wakes up after PulseEvent()
3) Processes whatever.
4) Calls PulseEvent on second event
Thread 3
1) WaitForSingleObject on second event handle
2) Processes whatever
Done
Is that how the program is supposed to act ?
-
January 2nd, 2007, 03:06 PM
#5
Re: Proper way to wait for a thread to return.
have any sample code for this? I just put a sleep in the loop for now.. doesn't seem like the best solution although it works.
-
January 2nd, 2007, 03:23 PM
#6
Re: Proper way to wait for a thread to return.
I guess the var m_rightClickFinished is set from outside the thread ? In that case declare m_rightClickFinished as volatile.
Code:
volatile bool m_rightClickFinished;
Alot of variables are cached in the CPU. What happens is that 1 thread sets a variable to true, but the CPU-cache doesn't update the other thread. To overcome this the volatile is invented. This says to the CPU not to cache the variable.
volatile : http://msdn2.microsoft.com/en-us/library/12a04hfd.aspx
-
January 4th, 2007, 09:32 AM
#7
Re: Proper way to wait for a thread to return.
I just want to give 1 comment on the good reply of mdmd. The function PulseEvent is unreliable according to Microsoft and should be avoided, see MSDN:
Originally Posted by MSDN
This function is unreliable and should not be used. It exists mainly for backward compatibility.
Better is to use SetEvent.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|