Aren/haiku
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

kernel/condition_variable: Clean up comments and reduce needless unlocks.

Browse Source 
This "race prevention" code does not seem to be really hit at all
in practice, at least from testing, so no need to do a full
unlock/lock universally for it.

I'm still not sure why the previous fixes here removed 80% of
the performance benefits of the original change; I need to
investigate that more.
This commit is contained in:
Augustin Cavalier 2019-08-05 22:58:28 -04:00
parent 2c588b031f
commit af0be8dbc5
1 changed files with 3 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
src/system/kernel/condition_variable.cpp
View File

@ -159,18 +159,13 @@ ConditionVariableEntry::Wait(uint32 flags, bigtime_t timeout)
entryLocker.Lock();
// Remove entry from variable, if not done yet. Since we are going to
// lock ourselves and recheck fVariable if it is not NULL, we don't need
// to acquire our own lock before doing this first NULL check.
// Remove entry from variable, if not done yet.
if (fVariable != NULL) {
if (fVariable == NULL)
return error;
SpinLocker conditionLocker(fVariable->fLock);
entryLocker.Unlock();
if (fVariable->fEntries.Contains(this)) {
fVariable->fEntries.Remove(this);
} else {
entryLocker.Unlock();
// The variable's fEntries did not contain us, but we currently
// have the variable's lock acquired. This must mean we are in
// a race with the variable's Notify. It is possible we will be
@ -178,8 +173,8 @@ ConditionVariableEntry::Wait(uint32 flags, bigtime_t timeout)
// spin until our fVariable member is unset by the Notify thread
// and then re-acquire our own lock to avoid a use-after-free.
while (atomic_pointer_get(&fVariable) != NULL) {}
entryLocker.Lock();
}
entryLocker.Lock();
fVariable = NULL;
}