We help IT Professionals succeed at work.

Check out our new AWS podcast with Certified Expert, Phil Phillips! Listen to "How to Execute a Seamless AWS Migration" on EE or on your favorite podcast platform. Listen Now


How to keep thread from hogging all CPU time

lajko asked
Medium Priority
Last Modified: 2010-04-05
I have a thread which does effect transitions between 2 images. It is for kiosks where they cycle through advertising "slides" when there is no user activity. It runs 2 separate monitors from the same program, each displaying their own set of slides. Now that I am adding video into the sequences, I notice some effects hog the cpu time and the video stalls briefly (although the sound is not interrupted) while the effect is running.

The core of the effect code is...
        do next step in effect
    until terminated or effect_is_finished

how can I get it to release cpu time and not use it all so the video or otherthings do not briefly stall?

Code was written by employee not with us, but we know how the uncommecnted code works. What we need is:

1. First step, due to not much time available for this item, is just to get it to not hog all cpu time during an effect. A simple "application.processmessages" doesn't seem to do it. I guess because the video running is not issuing any messages to be processed.

2. The second step will be to have this core of the effect do a step in the effect only once evert 30th to 50th of a second. After all, there is no need to update the image on the screen for each and every step of a slide in or other effect, which could be up to 800 steps (screen size 800x600). It would be better to update the progress of the effect in larger chunks at the same rate as NTSC video - 30 times a second (or 60 if you count interlacing) - which would leave plenty of time for video and other things to run. So how would we implement a timer in the above code to do this?

It should be easy for someone familiar with writing threads. This is the only thread code in the kiosk project and as I said before, the employee that wrote the thread isn't with us and the rest of us have never had to get into the writing of threads.
Watch Question

did you try setting the thread priority level to something lower


 MyThread.Priority := tpLower;


Insert a sleep(1) in the loop.

Unlock this solution and get a sample of our free trial.
(No credit card required)


winecex's answe was a start. However Geiff's answer was the most complete and explained what "sleep" did and how to control it. Adjusting the sleep time will allow the needed control over the effect timing and insure the videos on the other monitor are not interrupted. Now I can adjust the code for the effects to complete an effect in the specified time. Even though the timing would be approximate, that is OK for on-the-fly transitions between advertising slides.

Setting thread priority didn't properly stop/interrupt the effects once they got control of the processor.


First of all, try to write others' names correctly...
Second, it's simply outrageous. My answer was not a start, my answer was an EXACT solution for your problem. Or you might suggest that without the explanation of gmayo it wouldn't work? LMAO

Anyway, I'm not responding often here, I don't care much about points, but what you did was *LAME*...



Sometimes the keys on the keyboard move around. Sorry about the type-O's.

Your answer was a good answer. It would work. however, when weighed against other answers, it was not as complete. Geoff's answer explained the parameter and indicated the results of various values to the parameter. When looking at all the answers, you'll find that Geoff acknowledged your answer and expanded upon it. That is why I felt your answer was a good start but Geoff provided a more complete answer. I did not intend to demean you answer in any way at all.

Some of us prefer answers that include an explaination. Because of Geoff's explaination, I was able to tweek the transitions to give the optimal performance for both the transitions and the video running on the other screen. Without what he wrote, I would be reseaerching "sleep" and would not have been able to fix the problem in just about a half an hour.

Sorry you felt my response was "lame". It was not intended to be that way.

I like complete answers, even if they cover what I already know. Being a programmer since the early 70's, I know the problems of giving "blind" support. You never know the level of expertise of the person asking the question. Some people are quite offended when you include the "obvious" information, while others are offended if you don't include the most basic information for the question. What to do?  Sometimes you are never right.

I like as much information as possible, and just read through what I already know.

The facts are obvious:  you asked for a solution to your problem, you didn't ask for a detailed explanation, and my response solved completely your problem. By pushing that stupid sleep(1) in your thread the CPU usage became OK... Isn't it?
It would have been right to accept my comment as answer, and gmayo's comment as assisted answer, gmayo only detailed a little. Why that? Well, just because I responded correctly first, so are the forum rules.

"Some of us prefer answers that include an explaination." Yes, and if you prefer that, then it was your fault because you didn't specify it initially.

As I said, I really don't care about points, it's only a matter of principles. From my point what you did was wrong and that's all. Period.

Anyways, no problem :)


I feel it best to no longer continue this argumentative line of discussion.
If the forum moderators can close and lock this topic, I ask that you do so.
Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a sample view!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.