[Boost-users] boost::this_thread::sleep

Subject: [Boost-users] boost::this_thread::sleep
From: Sargrad, Dave (Dave.Sargrad_at_[hidden])
Date: 2012-02-01 06:07:59

Our software runs on both linux and solaris platforms. Our threads use boost threads, and will sleep using boost::this_thread::sleep(millisec)

On solaris we are using prstat to monitor the process and lightweight process details.

Prstat allows one to see thread level detail by using the –Lm option (prstat -Lm -p pid)

In this case a variety of information is output per thread (see prstat reference link at bottom of e-mail): for example system time (SYS), user time (USR), sleep time (SLP), and user lock time (LCK). 

The user lock time is time spent waiting by a thread for synchronization (protected) resources.

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? 

----------------------------------------------

As a point of reference pls see the following link, it talks to the LCK output of prstat.

http://www.scalingbits.com/performance/prstat

Please see the section labeled: prstat usage Scenario – Excessive Locking

Thanks in advance for any insights in this regard.
-
This message is intended only for the addressee and may contain information that is company confidential or privileged.  Any technical data in this message may be exported only in accordance with the U.S. International Traffic in Arms Regulations (22 CFR Parts 120-130) or the Export Administration Regulations (15 CFR Parts 730-774). Unauthorized use is strictly prohibited and may be unlawful. If you are not the intended recipient, or the person responsible for delivering to the intended recipient, you should not read, copy, disclose or otherwise use this message. If you have received this email in error, please delete it, and advise the sender immediately. 
-