This is an archive of the discontinued LLVM Phabricator instance.

[Support] Fix fragile ThreadPool test
ClosedPublic

Authored by aganea on Apr 24 2020, 2:44 PM.

Details

Summary

The test ThreadPoolTest.AllThreads_UseAllRessources occasionally fails on the bots: http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/32015/steps/test-check-all/logs/FAIL%3A%20LLVM-Unit%3A%3AThreadPoolTest.AllThreads_UseAllRessources

This is because jobs were executed too fast on the first CPU socket, and never manage to reach the second CPU socket.

Diff Detail

Event Timeline

aganea created this revision.Apr 24 2020, 2:44 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 24 2020, 2:44 PM
mehdi_amini added inline comments.Apr 24 2020, 5:19 PM
llvm/unittests/Support/ThreadPool.cpp
192

This still leaves the test sensitive to a timing effect, can we make it entirely deterministic?

For example can we increment a counter with a condition variable at the beginning of the lambda before waitForMainThread() and wait on the variable in the main thread until it reaches llvm::get_cpus() before calling into setMainThreadReady();?

aganea updated this revision to Diff 260095.Apr 25 2020, 7:41 AM

As suggested by @mehdi_amini

aganea marked an inline comment as done.Apr 25 2020, 7:41 AM
mehdi_amini accepted this revision.Apr 25 2020, 10:30 AM
This revision is now accepted and ready to land.Apr 25 2020, 10:30 AM
MaskRay accepted this revision.Apr 25 2020, 10:59 AM

LGTM as well.

llvm/unittests/Support/ThreadPool.cpp
184

Supposed this is deterministic now because of the llvm::ThreadPoolStrategy::apply_thread_strategy magic on Windows.

This revision was automatically updated to reflect the committed changes.