I'm using thread::yield() in my multi-threaded cross-platform application to avoid "CPU burn". This is because I have threads that are in an infinte loop in order to do some polling. There are no mutexes to wait on in the loop. void X::threadFunction() { for(;;) { if( m_x->isReady() ) doSomething(); . . . boost::thread::yield(); } } If the answer is "you should almost never poll like that - try to use mutexes etc. as much as possible" please say so (I'm a newbie to threads)! In any case, if I choose to have a thread in an infinite loop anyway, I have three options (assuming I have no mutexes available to me): 1. Don't yield or Sleep at all. 2. Sleep for a while - say for example, 10 ms. 3. Yield. Option 1 is clearly wrong. The CPU usage will go to 100% and the whole machine may slow down to an unusable speed. Option 2 works well in my emperical tests. The thread loop executes plenty fast enough and my Windows CPU meter shows virtually 0% CPU usage. 10ms is a bit of an arbitrary figure though - My code needs to work on a variety of software and hardware platforms, so the ideal number is hard or impossible to know. Option 3 also works well in my emperical tests and seems like the neat solution (no arbitrary waiting period). My application and the system as a whole both run smoothly and fast. The only irksome thing is that the CPU meter shows 100% usage. That's a bit alarming for me and the users of my software. My questions: 1. Should thread loops without logical wait conditions be avoided as much as possible? Is that the problem? 2. Should I just yield() or should I pause for a time period? 3. How do you select a time period to wait? Simon Bailey
On Thu, 2002-03-07 at 17:01, simonwlb wrote:
I'm using thread::yield() in my multi-threaded cross-platform application to avoid "CPU burn". <snip> { if( m_x->isReady() ) doSomething(); <..>
If the answer is "you should almost never poll like that - try to use mutexes etc. as much as possible" please say so (I'm a newbie to threads)!
The answer is actually probably conditionals plus mutexes. Presumably one thread is doing something, and other threads are waiting for it to be ready. This is a standard producer/consumer model. The consumers all wait on a condition variable, and the producer grabs the mutex, signals the condition variable, and then releases the mutex. One (or all, depending on how you signal) of the threads will wake up to deal with the signal. The advantage of this is the threads waiting on the signal are truly asleep, using 0% cpu. If you were using pthreads, I'd suggest looking up pthread_cond_signal and it's bretheren. I unfortunately don't know Boost's equivalents, but I'm sure they're similar. -- Colin Fox cfox@crystalcherry.com CF Consulting Inc. GPG Fingerprint: D8F0 84E7 E7CC 5C6C 9982 F1A7 A3EB 6EA3 BC97 572F [Non-text portions of this message have been removed]
I'm using thread::yield() in my multi-threaded cross-platform application to avoid "CPU burn". <snip> { if( m_x->isReady() ) doSomething(); <..>
If the answer is "you should almost never poll like that -
On Thu, 2002-03-07 at 17:01, simonwlb wrote: try to use
mutexes etc. as much as possible" please say so (I'm a newbie to threads)!
The answer is actually probably conditionals plus mutexes. Presumably one thread is doing something, and other threads are waiting for it to be ready. This is a standard producer/consumer model.
{ boost:
I'm using thread::yield() in my multi-threaded cross-platform application to avoid "CPU burn". <snip> { if( m_x->isReady() ) doSomething(); <..>
If the answer is "you should almost never poll like that -
On Thu, 2002-03-07 at 17:01, simonwlb wrote: try to use
mutexes etc. as much as possible" please say so (I'm a newbie to threads)!
The answer is actually probably conditionals plus mutexes. Presumably one thread is doing something, and other threads are waiting for it to be ready. This is a standard producer/consumer model.
// global variables boost::mutex g_mutex; boost::condition g_is_ready; // threads that are waiting { boost::mutex::scoped_lock lock(g_mutex); while(!m_x->isReady()) g_is_ready.wait(lock); doSomething(); // do our stuff now that other thread is ready } // thread that we're waiting on { ... g_is_ready.notify_one(); } - Dale. P.S. Sorry for the incomplete message before, my laptop has interesting key combos that keep catching me out.
At 01:01 AM 3/8/02 +0000, you wrote: [snip]
Option 1 is clearly wrong. The CPU usage will go to 100% and the whole machine may slow down to an unusable speed.
[snip] I've noticed that under Windows, at least with the 1.26.0 libraries, thread::sleep() causes the CPU to go up to 100%. However, it seems to be running at some sort of idle priority, as very few discernable effects are apparent when this happens. Steve
participants (4)
-
Colin Fox -
Dale Peakall -
simonwlb -
Steve Burnap