Jump to content

  • Log In with Google      Sign In   
  • Create Account


Making a "Busy Loop" not consume that much CPU (without Sleep)


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
23 replies to this topic

#21 Hodgman   Moderators   -  Reputation: 27025

Like
1Likes
Like

Posted 20 May 2013 - 08:29 PM

I'd like to point out that nobody has asked why the OP would like to inject a 0.2ms pause in his application.

Yeah they have tongue.png Looks like he's trying to make a sampling profiler:

I'm trying to sample another process (memory, stack, etc) and I'm checking the boundaries of what I can and cannot do (without using all the resources of the computer).



Sponsor:

#22 Promit   Moderators   -  Reputation: 5911

Like
0Likes
Like

Posted 20 May 2013 - 10:05 PM

I guess I missed that. When I wrote my profiler, I found that firing at 3ms intervals off a system timer was more than enough, and in fact you could bring down the sampling rate significantly if you were dealing with fairly repetitive processes like games tend to have. Actually my take on that is that it will cost you far more time to freeze your target's threads and walk the stacks than it will to deal with these little timing quirks.



#23 samoth   Crossbones+   -  Reputation: 4466

Like
1Likes
Like

Posted 21 May 2013 - 01:02 AM

Off topic: IIRC, there's also a rule in the scheduler where if a thread has been starved for 5 seconds, it will be boosted to the highest priority to ensure it gets at least 1 slice around once per 5 seconds (which is a very weak guarantee compared to what actual RT OS's give you laugh.png)

There's another such feature, which actually gives a quite good almost-RT behaviour (awesome in theory, in practice not always so) when using waitable timers as proposed by frob. When a waitable object becomes signalled, a thread waiting on it gets its priority temporarily boosted (presumably for 1 time slice, though the docs don't state for how long).

 

The Windows scheduler serves threads from highest priority downwards, serving higher priority threads until none is left, and also interrupts lower priority threads before their time slice has been used up when higher priority threads become ready.

That is, in theory (if nobody has tampered with process priorities, and no disk I/O thread is busy) this ensures that the thread actually runs "immediately" when the timer fires. Even though it doesn't always work quite as good as intended, in any case it's a not-totally-stupid approach that works more often than it doesn't, and it makes using waitable timers as good as you can get.



#24 Jason Z   Crossbones+   -  Reputation: 4581

Like
0Likes
Like

Posted 28 May 2013 - 04:49 PM

I think the original solution that the OP mentioned will also have the negative impacts that have been discussed throughout this thread.  If he sits in a loop spinning and checking the time elapsed, the thread could be pre-empted immediately before he reaches the desired elapsed time.  That would put his granularity at the mercy of the scheduler too, so I think the many good suggestions that have been given will provide equal precision to what he is currently using...

 

With that said, has the OP tried doing a series of NOP in his loop that he is checking the elapsed time in?  That would allow you to change the granularity of your checking, and reduce the power consumption of the loop at the same time.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS