Wait for event versus while / do loop or timer – academic questions
-
I have a worker thread running and would like to notify the main thread about changes in the worker thread. Call it synchronization if you prefer that. I understand “wait for event” does not load CPU (much or nil ) , per documentation. But if this is a worker thread of low priority would plain while / do loop load on CPU be also OK? Since I know approximately how often ( in seconds) the event occurs I could use timer also. The notification is asynchronous, not real time critical. Any comments on that? Cheers Vaclav
-
I have a worker thread running and would like to notify the main thread about changes in the worker thread. Call it synchronization if you prefer that. I understand “wait for event” does not load CPU (much or nil ) , per documentation. But if this is a worker thread of low priority would plain while / do loop load on CPU be also OK? Since I know approximately how often ( in seconds) the event occurs I could use timer also. The notification is asynchronous, not real time critical. Any comments on that? Cheers Vaclav
Even though the thread might be low priority, it will still cause 100% cpu usage. I would recommend strongly against it.
The difficult we do right away... ...the impossible takes slightly longer.
-
I have a worker thread running and would like to notify the main thread about changes in the worker thread. Call it synchronization if you prefer that. I understand “wait for event” does not load CPU (much or nil ) , per documentation. But if this is a worker thread of low priority would plain while / do loop load on CPU be also OK? Since I know approximately how often ( in seconds) the event occurs I could use timer also. The notification is asynchronous, not real time critical. Any comments on that? Cheers Vaclav
I think loop is the worst plan, it waste a lot of CPU cycle. timer is OK and sometime thread is a good solution
-
I have a worker thread running and would like to notify the main thread about changes in the worker thread. Call it synchronization if you prefer that. I understand “wait for event” does not load CPU (much or nil ) , per documentation. But if this is a worker thread of low priority would plain while / do loop load on CPU be also OK? Since I know approximately how often ( in seconds) the event occurs I could use timer also. The notification is asynchronous, not real time critical. Any comments on that? Cheers Vaclav
BTW, why do you want to wait on the worker thread? I simply don't understand this. Usually when a worker finishes with something you want to send an event to the "owner" of the worker thread immediately. do-loop / "spinning" is almost always a bad advice. Spinning is usually acceptable only in the form of a spin lock in some special cases of locking where it can terribly outperform normal locks. Thread priorities: Don't mess with thread priorities. Especially if your software is crossplatform. The best is to run everything on normal priority in most user space applications. In some cases setting the priority of some background data-loader threads to lower priority can help making the gui interaction smoother (usually if the machine is single-cpu and the IO terribly blocks on the background thread for some reason). What does the main thread do? Is it prepared for the event? Your job would be pretty easy if the main thread would be a gui thread or some other kind of thread that processes jobs/tasks from a blocking message queue. Timer??? Why do you need a timer and on which thread? Why don't you want to send the event from the worker thread immediately?
-
BTW, why do you want to wait on the worker thread? I simply don't understand this. Usually when a worker finishes with something you want to send an event to the "owner" of the worker thread immediately. do-loop / "spinning" is almost always a bad advice. Spinning is usually acceptable only in the form of a spin lock in some special cases of locking where it can terribly outperform normal locks. Thread priorities: Don't mess with thread priorities. Especially if your software is crossplatform. The best is to run everything on normal priority in most user space applications. In some cases setting the priority of some background data-loader threads to lower priority can help making the gui interaction smoother (usually if the machine is single-cpu and the IO terribly blocks on the background thread for some reason). What does the main thread do? Is it prepared for the event? Your job would be pretty easy if the main thread would be a gui thread or some other kind of thread that processes jobs/tasks from a blocking message queue. Timer??? Why do you need a timer and on which thread? Why don't you want to send the event from the worker thread immediately?
The main thread initialize worker thread whose job is to "send" timed audio to the main thread for processing (FFT). It is a test application, eventually it will be receiving real time data - audio - hence real time thread usage which will be time critical. I just posted a similar question, maybe that will explain why I do this such convoluted way. The key is how to monitor the WHDR_DONE flag which gets set AFTER the audio write is started / processed. In other words - I am missing the "link" between waveOutWrite and WHDR_DONE. waveOUtWrite by itself does not wait for the WHDR_DONE flag to set.
-
The main thread initialize worker thread whose job is to "send" timed audio to the main thread for processing (FFT). It is a test application, eventually it will be receiving real time data - audio - hence real time thread usage which will be time critical. I just posted a similar question, maybe that will explain why I do this such convoluted way. The key is how to monitor the WHDR_DONE flag which gets set AFTER the audio write is started / processed. In other words - I am missing the "link" between waveOutWrite and WHDR_DONE. waveOUtWrite by itself does not wait for the WHDR_DONE flag to set.
Well, I'm not familiar with that function call but it seems to me that the signaling of the completion of the data transfer is very primitive in this case and it seems that you will have to poll the flag. If its all about the right polling technique then... Depending on the architecture you may have to use at least an "acquire" memory barrier on the thread that polls the flag in order to notice the change in time. You start writing out a wave data chunk that is enough for the hardware for at least X milliseconds so your poll interval should probably be less than X/2 milliseconds to be successful but if the hardware has enough free buffer space then the transfer may complete in much shorter ("nearly zero"...) time then X milliseconds. If the precision of the OS scheduler is good enough then you can avoid busy-wait (do-loop) polling of the bit by sleeping for short periods between doing single-polls. If the OS scheduler isn't precise enough (for example because it can't put your thread to sleep state for shorter period then your Y poll period) then you have to do busy-waiting. Avoid busy waiting if possible, for example by writing out a large chunk that contains more than S*2 milliseconds of data if the period of the OS scheduler is S if possible. That way you can avoid busy waiting by polling this way: Sleep(S), check the flag, Sleep(S), check the flag,... This wont spin your poll thread. There are some situations when the only solution is spinning depending on the scenario but often it isn't.
-
I have a worker thread running and would like to notify the main thread about changes in the worker thread. Call it synchronization if you prefer that. I understand “wait for event” does not load CPU (much or nil ) , per documentation. But if this is a worker thread of low priority would plain while / do loop load on CPU be also OK? Since I know approximately how often ( in seconds) the event occurs I could use timer also. The notification is asynchronous, not real time critical. Any comments on that? Cheers Vaclav
Vaclav_Sal wrote:
I have a worker thread running and would like to notify the main thread about changes in the worker thread.
See the
PostMessage()comments here."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
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
-
Vaclav_Sal wrote:
I have a worker thread running and would like to notify the main thread about changes in the worker thread.
See the
PostMessage()comments here."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
"Show me a community that obeys the Ten Commandments and I'll show you a less crowded prison system." - Anonymous
