diff options
author | Abseil Team <absl-team@google.com> | 2023-06-16 01:48:02 -0700 |
---|---|---|
committer | Copybara-Service <copybara-worker@google.com> | 2023-06-16 01:48:42 -0700 |
commit | cef7c4e81afba04c30ead19cc689e337edbf1901 (patch) | |
tree | b9f89a506430d9aaa8efbea4cfc252295c936395 /absl/container/internal/compressed_tuple.h | |
parent | b6a417bbd7eba01b83a03748710d180372be5e67 (diff) | |
download | abseil-cef7c4e81afba04c30ead19cc689e337edbf1901.tar.gz abseil-cef7c4e81afba04c30ead19cc689e337edbf1901.tar.bz2 abseil-cef7c4e81afba04c30ead19cc689e337edbf1901.zip |
absl: fix Mutex writer starvation related to uninit priority
Currently when we queue the first thread, we don't init its priority.
Subsequent queued threads init priority, but they compare it against
the first thread priority, which is uninit. Thus the order can be wrong.
It can lead to complete false starvation in some corner cases.
On Linux the default priority is 0, which matches the uninit value,
thus the problem is harder to spot on Linux (only possible if explicit
thread priorities are used). But on Darwin the default priority is 31,
thus the first thread falsely looks like lower priority than subsequently
queued threads. The added test exposes the problem on Darwin.
Always initialize the priority before queuing threads.
PiperOrigin-RevId: 540814133
Change-Id: I513ce1493a67afe77d3e92fb49000b046b42a9f2
Diffstat (limited to 'absl/container/internal/compressed_tuple.h')
0 files changed, 0 insertions, 0 deletions