Board index » Visual Studio » OnTimer priority

Visual Studio263
I my control system i am using OnTimer() to run control routines as serial

communication, calculations and control routines. The code runing on timer

is big alredy and it is growing....causing bad PC performance. I think i am

wrong in using timer for this task as moving dialogs around the screen will

stop or delay the timer event. Appreciate if someone could tell me the best

way of preventing userinterface operation from interfering with performance

of my background tasks, and for big background tasks not to freeze

userinterface.


-

=D8yvind Hansen wrote:

I would create one or more threads to handle the routines your OnTimer=20

is doing. Have the threads go into a "sleep" state when not ready to=20

execute some code by using something like WaitForSingleObject,=20

WaitForMultipleObjects, etc with timeout delays.



With threads (one or more) doing the same task as the OnTimer, that=20

leaves the UI and application responsive while the threads are working aw=

ay.



Relvinian



-

"Øyvind Hansen" <oyvind@scantrol.no>wrote in message

At the end of the day:



(1) you can't burn more CPU cycles in a given time than your processor is

capable of delivering.

(2) Windows is not a real-time operating system



so you're on a loser; you can't "solve" this type of problem, you can only

make it "better", but if you're lucky "better" may turn out to be "good

enough".



Certainly you should run your non-GUI routines in another thread to remove

the absolute interdependence that you are currently seeing. However CPU

cycles are still CPU cycles, and if you give the new thread higher priority

then the GUI might get a bit less responsive, and if you give the new thread

lower priority then you might not get the work done in a cycle if someone

starts playing with the GUI.



I did once have a thread doing some machine control switch itself to real

time priority for the critical part of its cycle, which worked - but of

course the GUI froze completely for every other half second (or whatever it

was) and basically I was lucky (with things like the operating system still

being able to write the results to disk) as Windows is not designed to be

used like that.



--

Tim Ward

Brett Ward Limited - www.brettward.co.uk





-

Øyvind Hansen wrote:

Using separate threads for your lengthy non-GUI tasks will give you two

advantages: The GUI and the tasks will run concurrently with less

interference with each other, and the SetThreadPriority API will let you

control the relative priority of the GUI and non-GUI threads.



Your thread can consist of a loop that contains WaitForMultipleObjects

with a timeout. That will suspend the thread for the time you set, and

you will also get more consistent timing than OnTimer in a GUI thread

can give you.



--

Scott McPhillips [VC++ MVP]



-

On Fri, 3 Dec 2004 09:12:28 +0100, Øyvind Hansen wrote:



Repeat after me : threads.



I have a short example of a simple worker thread on my website here:



bobmoore.mvps.org/Win32/framed_tip031.htm">bobmoore.mvps.org/Win32/framed_tip031.htm



Which should get you started. Feel free to plagiarise, it's in the

great tradition of software development :-)



--

Bob Moore

bobmoore.mvps.org/">bobmoore.mvps.org/

(this is a non-commercial site and does not accept advertising)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Do not reply via email unless specifically requested to do so.

Unsolicited email is NOT welcome and will go unanswered.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-