Reland of Ensure consistent return ordering in base::WaitableEvent::WaitMany

Reland of Ensure consistent return ordering in base::WaitableEvent::WaitMany (patchset #1 id:1 of https://codereview.chromium.org/2761993004/ )

Reason for revert:
Even if this did negatively impact telemetry performance, we'd want the WaitMany change for the sake of API correctness.

However, after leaving the revert in place for a day, it doesn't look like this CL was the culprit anyway.

Original issue's description:
> Revert of Ensure consistent return ordering in base::WaitableEvent::WaitMany (patchset #5 id:80001 of https://codereview.chromium.org/2758853002/ )
> 
> Reason for revert:
> Causing extra time for chrome_public_test_apk, telemetry_perf_unittests etc.
> 
> Original issue's description:
> > Ensure consistent return ordering in base::WaitableEvent::WaitMany
> > 
> > The Windows implementation (via WaitForMultipleObjects) guarantees that
> > if multiple objects are signaled, the one with the smallest index is
> > returned on wakeup. This is a useful guarantee to make, as callers are
> > granted the ability to rotate objects as needed to avoid potential
> > starvation of lower-frequency events.
> > 
> > The POSIX implementation of WaitMany does not support this behavior, as
> > precedence is determined exclusively by WaitableEvent address order
> > rather than input array order. The behavior today is a result of the
> > implementation detail that we must lock the WaitableEvent kernels in a
> > globally consistent order, and this makes it effectively impossible for
> > a caller to control signaling priority.
> > 
> > This CL changes the POSIX implementation to guarantee the same return
> > behavior as the Windows implementation, allowing the WaitMany API to in
> > turn guarantee left-to-right precedence of the WaitableEvents with which
> > it's called.
> > 
> > This has some minor additional cost as we no longer short-circuit on the
> > first signaled event we find, and we always have to iterate over the array
> > twice now. This cost is negligible in practice as WaitMany is only ever
> > used in production with a small (n < 5) number of events.
> > 
> > BUG=698460
> > 
> > Review-Url: https://codereview.chromium.org/2758853002
> > Cr-Commit-Position: refs/heads/master@{#457967}
> > Committed: https://chromium.googlesource.com/chromium/src/+/926b72bf8aba665d906fe411a11a9f587335c1bb
> 
> TBR=dcheng@chromium.org,rockot@chromium.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=698460
> 
> Review-Url: https://codereview.chromium.org/2761993004
> Cr-Commit-Position: refs/heads/master@{#458602}
> Committed: https://chromium.googlesource.com/chromium/src/+/a0a9840a39b61caca179486dcf20927fe99ad4a6

TBR=dcheng@chromium.org,hzl@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=698460
Review-Url: https://codereview.chromium.org/2773463002
Cr-Commit-Position: refs/heads/master@{#458843}
Committed: https://chromium.googlesource.com/chromium/src/+/6622a12c5f8f585045e0b91e9b20a1a1b499fcb2

[Ken Rockot(use gerrit already), 2017-03-22 19:33:43]

The CQ bit was checked by rockot@chromium.org

[Ken Rockot(use gerrit already), 2017-03-22 19:33:43]

Created Reland of Ensure consistent return ordering in
base::WaitableEvent::WaitMany

[commit-bot: I haz the power, 2017-03-22 19:34:55]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-22 19:38:08]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1490211223019420, "parent_rev":
"69708855a86d235ff43a11c1b525f8518e608056", "commit_rev":
"6622a12c5f8f585045e0b91e9b20a1a1b499fcb2"}

[commit-bot: I haz the power, 2017-03-22 19:38:52]

Description was changed from

==========
Reland of Ensure consistent return ordering in base::WaitableEvent::WaitMany
(patchset #1 id:1 of https://codereview.chromium.org/2761993004/ )

Reason for revert:
Even if this did negatively impact telemetry performance, we'd want the WaitMany
change for the sake of API correctness.

However, after leaving the revert in place for a day, it doesn't look like this
CL was the culprit anyway.

Original issue's description:
> Revert of Ensure consistent return ordering in base::WaitableEvent::WaitMany
(patchset #5 id:80001 of https://codereview.chromium.org/2758853002/ )
> 
> Reason for revert:
> Causing extra time for chrome_public_test_apk, telemetry_perf_unittests etc.
> 
> Original issue's description:
> > Ensure consistent return ordering in base::WaitableEvent::WaitMany
> > 
> > The Windows implementation (via WaitForMultipleObjects) guarantees that
> > if multiple objects are signaled, the one with the smallest index is
> > returned on wakeup. This is a useful guarantee to make, as callers are
> > granted the ability to rotate objects as needed to avoid potential
> > starvation of lower-frequency events.
> > 
> > The POSIX implementation of WaitMany does not support this behavior, as
> > precedence is determined exclusively by WaitableEvent address order
> > rather than input array order. The behavior today is a result of the
> > implementation detail that we must lock the WaitableEvent kernels in a
> > globally consistent order, and this makes it effectively impossible for
> > a caller to control signaling priority.
> > 
> > This CL changes the POSIX implementation to guarantee the same return
> > behavior as the Windows implementation, allowing the WaitMany API to in
> > turn guarantee left-to-right precedence of the WaitableEvents with which
> > it's called.
> > 
> > This has some minor additional cost as we no longer short-circuit on the
> > first signaled event we find, and we always have to iterate over the array
> > twice now. This cost is negligible in practice as WaitMany is only ever
> > used in production with a small (n < 5) number of events.
> > 
> > BUG=698460
> > 
> > Review-Url: https://codereview.chromium.org/2758853002
> > Cr-Commit-Position: refs/heads/master@{#457967}
> > Committed:
https://chromium.googlesource.com/chromium/src/+/926b72bf8aba665d906fe411a11a...
> 
> TBR=dcheng@chromium.org,rockot@chromium.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=698460
> 
> Review-Url: https://codereview.chromium.org/2761993004
> Cr-Commit-Position: refs/heads/master@{#458602}
> Committed:
https://chromium.googlesource.com/chromium/src/+/a0a9840a39b61caca179486dcf20...

TBR=dcheng@chromium.org,hzl@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=698460
==========

to

==========
Reland of Ensure consistent return ordering in base::WaitableEvent::WaitMany
(patchset #1 id:1 of https://codereview.chromium.org/2761993004/ )

Reason for revert:
Even if this did negatively impact telemetry performance, we'd want the WaitMany
change for the sake of API correctness.

However, after leaving the revert in place for a day, it doesn't look like this
CL was the culprit anyway.

Original issue's description:
> Revert of Ensure consistent return ordering in base::WaitableEvent::WaitMany
(patchset #5 id:80001 of https://codereview.chromium.org/2758853002/ )
> 
> Reason for revert:
> Causing extra time for chrome_public_test_apk, telemetry_perf_unittests etc.
> 
> Original issue's description:
> > Ensure consistent return ordering in base::WaitableEvent::WaitMany
> > 
> > The Windows implementation (via WaitForMultipleObjects) guarantees that
> > if multiple objects are signaled, the one with the smallest index is
> > returned on wakeup. This is a useful guarantee to make, as callers are
> > granted the ability to rotate objects as needed to avoid potential
> > starvation of lower-frequency events.
> > 
> > The POSIX implementation of WaitMany does not support this behavior, as
> > precedence is determined exclusively by WaitableEvent address order
> > rather than input array order. The behavior today is a result of the
> > implementation detail that we must lock the WaitableEvent kernels in a
> > globally consistent order, and this makes it effectively impossible for
> > a caller to control signaling priority.
> > 
> > This CL changes the POSIX implementation to guarantee the same return
> > behavior as the Windows implementation, allowing the WaitMany API to in
> > turn guarantee left-to-right precedence of the WaitableEvents with which
> > it's called.
> > 
> > This has some minor additional cost as we no longer short-circuit on the
> > first signaled event we find, and we always have to iterate over the array
> > twice now. This cost is negligible in practice as WaitMany is only ever
> > used in production with a small (n < 5) number of events.
> > 
> > BUG=698460
> > 
> > Review-Url: https://codereview.chromium.org/2758853002
> > Cr-Commit-Position: refs/heads/master@{#457967}
> > Committed:
https://chromium.googlesource.com/chromium/src/+/926b72bf8aba665d906fe411a11a...
> 
> TBR=dcheng@chromium.org,rockot@chromium.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=698460
> 
> Review-Url: https://codereview.chromium.org/2761993004
> Cr-Commit-Position: refs/heads/master@{#458602}
> Committed:
https://chromium.googlesource.com/chromium/src/+/a0a9840a39b61caca179486dcf20...

TBR=dcheng@chromium.org,hzl@google.com
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=698460

Review-Url: https://codereview.chromium.org/2773463002
Cr-Commit-Position: refs/heads/master@{#458843}
Committed:
https://chromium.googlesource.com/chromium/src/+/6622a12c5f8f585045e0b91e9b20...
==========

[commit-bot: I haz the power, 2017-03-22 19:38:53]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/chromium/src/+/6622a12c5f8f585045e0b91e9b20...

[dcheng, 2017-03-22 19:56:21]

On 2017/03/22 19:38:53, commit-bot: I haz the power wrote:
> Committed patchset #1 (id:1) as
>
https://chromium.googlesource.com/chromium/src/+/6622a12c5f8f585045e0b91e9b20...

LGTM