Race conditions between successful locks after having set the
waiters flag and unlocks exist. If a lock (both priority mutex or
priority RW lock not as a next-waiter) is successfully locked this
way, the corresponding waiter flag is set even though other
waiters on the corresponding event do not necessarily exist.
Then, on unlock, this higher-priority event with no waiters might
be signaled while a lower-priority event with waiters will not
be signaled.
This is fixable by adjusting priority mutex high_priority_waiters
and rw lock high_priority_x_waiters and high_priority_s_waiters
flags to be atomically incremented instead of setting to 1 and
atomically decremented instead of doing nothing if locking
succeeds after setting the flag. high_priority_wait_ex_waiter
flag can be maintained as 0/1 as described in the previous
comment.
The already-existing mutex::waiters and lock::waiters flag need
not to be adjusted this way as there are no lower-priority events
below them. Although such adjustment would result in a bit less
spurious wakeup events under load and might be done as needed in
the future.
Race conditions between successful locks after having set the
waiters flag and unlocks exist. If a lock (both priority mutex or
priority RW lock not as a next-waiter) is successfully locked this
way, the corresponding waiter flag is set even though other
waiters on the corresponding event do not necessarily exist.
Then, on unlock, this higher-priority event with no waiters might
be signaled while a lower-priority event with waiters will not
be signaled.
This is fixable by adjusting priority mutex high_priority_ waiters x_waiters and high_priority_ s_waiters wait_ex_ waiter
and rw lock high_priority_
flags to be atomically incremented instead of setting to 1 and
atomically decremented instead of doing nothing if locking
succeeds after setting the flag. high_priority_
flag can be maintained as 0/1 as described in the previous
comment.
The already-existing mutex::waiters and lock::waiters flag need
not to be adjusted this way as there are no lower-priority events
below them. Although such adjustment would result in a bit less
spurious wakeup events under load and might be done as needed in
the future.