How not to hog CPU while waiting for some event?

Question

I would like to write some code that wakes up on (or sleep until) some event.

I have a piece of code that sleeps until some event happens, such as when alarmed by a clock.

Pseudo code:

int main() {
  TimePoint someTp("3PM");
  std::this_thread::sleep_until(someTP);
}

This is my current implementation, but this hogs about 10% of my CPU power. I think my design is flawed, is there any better solution for this? Many thanks in advance!

sleep shouldn't hog CPU - how are you determining it hogs 10% of the CPU? — Jeff Foster, Jun 09 '11 at 16:23
A truly sleeping thread should never use any CPU. What are you using to measure CPU usage? — Ates Goral, Jun 09 '11 at 16:23
Hi, sorry. I am using Linux System Monitor. Perhaps this is not accurate? — will, Jun 09 '11 at 16:24
Due to the amount of polling and rendering system monitors need to do, they eat up some CPU on their own. You should specifically check the CPU usage of your _process_ rather than the overall system. — Ates Goral, Jun 09 '11 at 16:33
@Sam Miller - TimePoint is like a boost::posix_time object, i.e. HH-MM-SS. — will, Jun 09 '11 at 17:08
@Ates Goral - Thanks. You are right. I will do some kind of profiling on the app specifically. — will, Jun 09 '11 at 17:09

score 8 · Answer 1 · edited May 23 '17 at 12:26

8

The problem is in the implementation of std::this_thread:sleep_until(..) which calls sleep_for(..), which calls nanosleep().

(See the gnu sources, line 271.)

See the following Stackoverflow questions:

nanosleep high cpu usage? (Linux high-cpu issue calling nanosleep.)
boost::this_thread::sleep() vs. nanosleep()?

You don't appear to need the high resolution of nanosleep(). You might write your own solution with a permissive open source license, and call sleep() instead of nanosleep().

If you do need sub-second resolution, I recommend the technique of calling select() rather than nanosleep(). select() is designed to block very efficiently for sub-second delays, and the timeout parameter is respected accurately enough by most operating systems that it is useful for sub-second timing while yielding the CPU.

You can even create a socket for the purpose of passing to select(), in theerror_fds parameter, where the socket can be used as a cross-thread "signal" when it is passed to close() and becomes an "error" state socket.

edited May 23 '17 at 12:26

Community

1
1

answered Jun 09 '11 at 16:33

Heath Hunnicutt

18,667
3
39
62

What would switching to a permissive license achieve? – Luc Danton Jun 09 '11 at 16:56
Many thanks for the advice. I use gcc's c++0x std::this_thread::sleep_for actually. I will consider your suggestions. – will Jun 09 '11 at 17:10
1

@ildjarn -- The same problem has been reported post 2.6.22, so I disagree. – Heath Hunnicutt Jun 09 '11 at 18:15
Ah, the page I was looking at didn't mention that, only the 2.5.39 change. Good to know :-] – ildjarn Jun 09 '11 at 18:21

score 3 · Answer 2 · edited Jun 10 '12 at 20:53

3

A better solution would be using an event driven library such as Boost.Asio or libevent rather than sleeping for some duration.

edited Jun 10 '12 at 20:53

robert

33,242
8
53
74

answered Jun 09 '11 at 16:43

Sam Miller

23,808
4
67
87

score 1 · Answer 3 · answered Jun 09 '11 at 16:40

1

A simple implementation can be to use a Semaphore.

Keep your worker thread blocked on a semaphore and signal the semaphore from another thread where the alarm clock event occurs.

void* workerThread(void*) 
{
     TimePoint someTp("3PM");
     sem_Wait();    //Thread remains blocked here
}

void timercallback()
{
    sem_post(); //Signals worker thread to move ahead

}

answered Jun 09 '11 at 16:40

Alok Save

202,538
53
430
533

+1 [Always prefer a semaphore to a busy wait](http://randomascii.wordpress.com/2012/06/05/in-praise-of-idleness/). – Laurent Couvidou Jun 10 '12 at 20:57
Waiting idle is certainly better than busy waiting (thanks for the link to my blog post), but I'm not sure what a semaphore achieves here. You have a timercallback() which somehow (you don't say how) is called when the time expires. Why not just run your code in the callback? There may be a reason but it isn't described. That is, in your sample solution the important detail (how to schedule a timercallback) is omitted. Also, thankfully, the OP never suggested busy waiting. – Bruce Dawson May 13 '15 at 00:26

How not to hog CPU while waiting for some event?

3 Answers3