Scarfski/filament
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

JobSystem: signal condition with lock held

Browse Source 
This seems to improve parallelism on multicores and at least on
Android, doesn't seem to impact performance.
This commit is contained in:
Mathias Agopian
2021-06-03 10:43:06 -07:00
committed by Mathias Agopian
parent a4280881d5
commit c5ef1d6252
9 changed files with 15 additions and 37 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
libs/utils/src/JobSystem.cpp
View File

@@ -193,9 +193,8 @@ void JobSystem::decRef(Job const* job) noexcept {
void JobSystem::requestExit() noexcept {
mExitRequested.store(true);
{ std::lock_guard<Mutex> lock(mWaiterLock); }
std::lock_guard<Mutex> lock(mWaiterLock);
mWaiterCondition.notify_all();
}
inline bool JobSystem::exitRequested() const noexcept {
@@ -249,17 +248,10 @@ void JobSystem::wait(std::unique_lock<Mutex>& lock, Job* job) noexcept {
}
void JobSystem::wake() noexcept {
Mutex& lock = mWaiterLock;
lock.lock();
std::lock_guard<Mutex> lock(mWaiterLock);
// this empty critical section is needed -- it guarantees that notifiy_all() happens
// after the condition variables are set.
// We signal the condition inside the lock (which is not required), because this seems to
// yield to better scheduling on Android. When we signal outside the critical section,
// it looks like this thread gives its time slice to the waking thread and just sits there
// being runnable, but not running.
mWaiterCondition.notify_all();
lock.unlock();
}
inline JobSystem::ThreadState& JobSystem::getState() noexcept {