Using HPX's mutex and condition_variable leads to 99% CPU usage #6545
-
Hello, hpx.max_idle_loop_count=1000
hpx.max_idle_backoff_time=1000 I used HPX-provided Here's how my custom ResultRs<vector<byte>, ErrorRs> Xdma::read(const int64_t timeout)
{
// size_t m_maxSizeCacheQue;
// std::queue<std::vector<std::byte>> m_cacheQue;
// hpx::mutex m_cacheLock;
// hpx::condition_variable m_cacheCond;
ResultRs<IntfCardFrame, ErrorRs> ret = ErrorRs::withCode(ErrorKind::Other);
std::unique_lock guard(m_cacheLock);
if (0 == timeout)
{
if (true == m_cacheQue.empty())
{
return ErrorRs::withCode(ErrorKind::ResourceNotAvailable);
}
}
else if (timeout < 0)
{
m_cacheCond.wait(guard, [&]{
return false == this->m_cacheQue.empty();
});
}
else
{
auto retBool = m_cacheCond.wait_for(guard, std::chrono::milliseconds(timeout), [&]{
return false == this->m_cacheQue.empty();
});
if (false == retBool)
{
return ErrorRs::withCode(ErrorKind::Timeout);
}
}
auto item = std::move(m_cacheQue.front());
m_cacheQue.pop();
return item;
} During testing, I noticed that even when the shared queue is empty, using |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
The HPX synchronization primitives ( For this reason, the CPUs are still utilized 100% as the kernel threads that run the scheduling loop for HPX threads keep churning along. If you want to reduce CPU utilization in case if no HPX work is available and ready to run, you can use
first thing inside |
Beta Was this translation helpful? Give feedback.
The HPX synchronization primitives (
semaphore
,condition_variable
, etc.) suspend the running HPX (user-level) thread, not the underlying kernel (p-) thread. This is done to allow for other HPX threads to run while a particular one is blocked.For this reason, the CPUs are still utilized 100% as the kernel threads that run the scheduling loop for HPX threads keep churning along.
If you want to reduce CPU utilization in case if no HPX work is available and ready to run, you can use
first thing inside
hpx_main
that instructs the main scheduling loop to put the underlying kernel thread to sleep much fas…