Le 01/02/12 12:07, Sargrad, Dave a écrit :
Our software runs on both linux and solaris platforms. Our threads use boost threads, and will sleep using boost::this_thread::sleep(millisec)
<snip> Interestingly all of our threads show up with a high-level of user lock time. Wanting to understand this I spent time today isolating the user lock time to the call to boost::this_thread::sleep(1000).
When our thread did nothing but wake up and go back to sleep for 1000 milliseconds the thread would show up with 100% LCK rather than 100% SLP.
As an experiment I replaced the single call to boost::this::thread::sleep(1000) with a comparable call to nanosleep(). In this case the thread shows up as 100% SLP, rather than 100% LCK (and looks more like what I would have expected).
Having read a bit more about the boost::this_thread::sleep I believe that this may be because the boost sleep implementation actually uses a mutex (synchronization object) and hence the thread really is waiting for a synchronization resource.
I’ve come to the conclusion that this “100 % locked” indicator for our threads is not necessarily indicative of a problem, rather it is just an artifact of the boost::this_thread::sleep implementation.
I’m still a bit queasy about this and would like some confirmation from the experts. Is the fact that our boost threads (when sleeping) show up as 100% locked rather than 100% sleeping a problem, or is it just an artifact of the boost thread implementation? Hi,
I agree that it will be better if this_thread::sleep uses platform specifics that show your program is sleeping. I see however the code in libs/thread/src/pthread/thread.cpp void sleep(const system_time& st) ... # elif defined(BOOST_HAS_NANOSLEEP) timespec ts; to_timespec_duration(xt, ts); // nanosleep takes a timespec that is an offset, not // an absolute time. nanosleep(&ts, 0); which uses nanosleep when available. Could you check if BOOST_HAS_NANOSLEEP is defined on Solaris? Hint:Add an #error after the elif. Best, Vicente