|
I have created a thread using CreateThread() function
The thread function is as follows:
void backtrack(LPVOID)
{
while(1)
{
Sleep(iDelay); //iDelay is a global int variable
__________ //iDelay default value is 10000
__________
.
.
}
}
iDelay is a global int variable whose default value is 10000(10 minutes). The user can change the delay variable iDelay when the thread is running.
OnChangedelay()
{
iDelay = //Get input from user using a dialog window
SuspendThread(htBackTrackThread);
ResumeThread(htBackTrackThread);
}
My Question is:
When the thread is running with default Sleep time iDelay = 10000, I changed the Sleep time to 1000 using the OnChangedelay() function. But the new delay time takes effect only after 10 minutes which is the old delay time. I guess that since the thread has executed the sleep statement and in the sleep mode for 10 minutes, I am not able to suspend the thread and resume the thread with the new delay time.
Any solution to suspend the thread immediately even if it is in Sleep()
modified 27-Sep-11 7:02am.
|
|
|
|
|
|
Actually, My question is How to suspend a thread when it is in Sleep mode
|
|
|
|
|
Use the alertable SleepEx[^] function.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
modified 27-Sep-11 8:53am.
|
|
|
|
|
Excellent answer. Though the link needs an 'x' on the end to make it end ".aspx". 
If I'd been the original developer of SleepEx, I would have called it the WakeUp() function instead.
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
|
|
|
|
|
Fixed, thank you.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
manoharbalu wrote: iDelay is a global int variable whose default value is 10000(10 minutes).
If you are after 10 minutes, you might want to consider 600000 milliseconds, otherwise you're looking at about 10 seconds.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
Hi,
I use the CWinThread class to have my CDialog GUI stay responsive while doing some lengthy calculation. However, my thread needs to stay alive, since it can receive some notification anytime while my application runs. The problem I have is that after InitInstance is done, my thread automatically enters the ExitInstance method, which I do not want. However, I want my thread to stay alive until I close my CDialog, and then enter ExitInstance. Any idea how this can be performed?
Thanks alot.
|
|
|
|
|
Normally in a thread routine you have a while() loop, normally the condition is a 'staytalive' or some such, that is set FALSE when you want the thread to terminate.
==============================
Nothing to say.
|
|
|
|
|
CWinThreads have this built in already... They don't require anything looping be done by the dev.
|
|
|
|
|
Absolutely! I've actually seen people overriding the run method and squeeze in an infinite loop there. When I tell them "that's what it already does, may be what you need is a worker thread?", they'll be like "oh yeah, that makes sense". A lot of people using spawning UI threads don't actually know that they're spawning a, well, UI thread.
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
 I use CWinThreads quite a bit... I actually like them, they're easy to use and communicate with...
|
|
|
|
|
By the way, see my note[^] below regarding the UI naming convention.
|
|
|
|
|
Before creating the thread, create an "Event" object, closed, not auto-reset. When the thread is ready to exit, use WaitForSingleObject() to wait for the event to be triggered. When the dialog closes, have use SetEvent() to tell the thread that it is ok for it to exit now.
|
|
|
|
|
CWinThreads don't require this... you can WaitForSingleObject() on the thread handle itself after you've asked the thread to go down with a WM_QUIT message.
|
|
|
|
|
In my opinion, interthread activities should be explicitly stated rather than rely on side effects of other things.
A "permission to exit" signal is one way of formalizing those activities. "Permission to start" is another. The fact that a thread was created doesn't necessarily mean that it can immediately being doing processing. My threads always go through several stages:
1) Initialization at the start address of the thread
2) Signals an "initialization done" event to allow the main thread to create more, knowing that any data structures, other events / objects are created and that the created thread is ready to run
3) Waits for a "permission to start" event. This allows the main thread to delay start of the thread until other threads are created and ensures that subsequent threads have created their objects that may be necessary for interthread communication to work.
4) enters the "run state" where it is now doing its job
5) "permission to exit" is optional and only when you want the "dance of the threads" to end in an orderly fashion.
You want this orderly approach to startup and shutdown to ensure that if you create many threads, some of which need to communicate with each other, those threads do not run into timing problems and access objects that may not be created / initialized yet by other threads.
Also, I have no idea why you downvoted my answer, it was not wrong, just not to your liking.
|
|
|
|
|
Chuck O'Toole wrote: Also, I have no idea why you downvoted my answer, it was not wrong, just not to your liking.
CWinThreads aren't used in this fashion... besides, trace back on your other solutions... I'm sure I've upvoted you numerous times (I know I have). Keep up the responses, I'm sure you'll get plenty more  from me.
|
|
|
|
|
A CWinThread shouldn't do this automatically (in regular operation). Don't forget to override the InitInstance to return a value, not overriding results in the thread thinking it has nothing to do. Another possible cause is the auto-delete feature being triggered somehow, it's controlled via a public variable so you can simply set it to false to make sure that's not causing this behavior.
|
|
|
|
|
From your description it sounds like you have your threads backwards. Your doing the work in a UI thread and trying to spawn another UI thread to keep your UI active.
In fact the UI thread should start a worker thread to do the lengthy operation. Then the UI thread can continue to service the user actions.
If you vote me down, my score will only get lower
|
|
|
|
|
That's how I understood it too. As well, putting a dialog in another CWinThread sounds more like needing a modeless dialog instead of a modal one. 
Chris Meech
I am Canadian. [heard in a local bar]
In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
posting about Crystal Reports here is like discussing gay marriage on a catholic church’s website.[Nishant Sivakumar]
|
|
|
|
|
Excellent answer, Roger.
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
The UI name is simply a naming convention that MS picked up a long time ago, it doesn't necessarily mean that a CWinThread needs to work with a user interface. Its useful when you need a working thread that's persistent, meaning it doesn't do a job then end.
|
|
|
|
|
If you're implying that "UI thread" is some kind of an inappropriate name, I can't agree with you more. I've used these "UI" threads in several instances where there's no UI. For example, if I needed some kind of a queued event processing mechanism within my program that will process requests in the order they were received, then UI thread would be a quick and reliable way to do it.
BTW, Roger is correct in saying that the OP should rather delegate lengthy tasks to a background worker, and not bother the main thread that processes the dialog UI events.
"Real men drive manual transmission" - Rajesh.
|
|
|
|
|
Exactly! 
Don't know exactly where that name started, but it stuck apparently. Should be more of a "Persistent thread" or something similar.
|
|
|
|
|
If you need to perform a lengthy calculation, spawn a worker thread and let it do that. The UI thread should not be burdened with anything else but responding to the user.
"Real men drive manual transmission" - Rajesh.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
