public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Alexandre Oliva <aoliva@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org, libstdc++-cvs@gcc.gnu.org Subject: [gcc r13-6464] libstdc++: testsuite: async.cc early timeout Date: Fri, 3 Mar 2023 20:14:19 +0000 (GMT) [thread overview] Message-ID: <20230303201419.335683858D28@sourceware.org> (raw) https://gcc.gnu.org/g:16554ba1fe66a09f99adde1220a2cd4f7e5e2d64 commit r13-6464-g16554ba1fe66a09f99adde1220a2cd4f7e5e2d64 Author: Alexandre Oliva <oliva@adacore.com> Date: Wed May 4 23:41:38 2022 -0300 libstdc++: testsuite: async.cc early timeout The async call and future variable initialization may take a while to complete on uniprocessors, especially if the async call and other unrelated processes run before context switches back to the main thread. Taking steady_begin only then sometimes causes the 11*100ms in the slow clock, counted from before the async call, to not be enough for the measured wait to last 1s in the steady clock. I've seen it fall short of 1s by as little as a third of a tenth of a second in some cases, but in one surprisingly extreme case the elapsed wait time got only up to 216.7ms. Initializing both timestamps next to each other, before the async call, appears to avoid the problem entirely. I've renamed the variable moved out of the block so as to avoid name hiding in the subsequent block, that has another steady_begin variable. The second wait fails a lot less frequently, but the 2s limit has been exceeded, so I'm bumping up the max sleep to ~4s, and the tolerance to 3s. for libstdc++-v3/ChangeLog * testsuite/30_threads/async/async.cc (test04): Initialize steady_start, renamed from steady_begin, next to slow_start. Increase tolerance for final wait. Diff: --- libstdc++-v3/testsuite/30_threads/async/async.cc | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/libstdc++-v3/testsuite/30_threads/async/async.cc b/libstdc++-v3/testsuite/30_threads/async/async.cc index 2687e92ee40..4e290e581c2 100644 --- a/libstdc++-v3/testsuite/30_threads/async/async.cc +++ b/libstdc++-v3/testsuite/30_threads/async/async.cc @@ -20,6 +20,7 @@ // with this library; see the file COPYING3. If not see // <http://www.gnu.org/licenses/>. +#include <iostream> #include <future> #include <thread> @@ -133,6 +134,7 @@ void test04() { using namespace std::chrono; + auto const steady_start = steady_clock::now(); auto const slow_start = slow_clock::now(); future<void> f1 = async(launch::async, []() { std::this_thread::sleep_for(std::chrono::seconds(2)); @@ -140,21 +142,26 @@ void test04() // Wait for ~1s { - auto const steady_begin = steady_clock::now(); auto const status = f1.wait_until(slow_start + milliseconds(100)); VERIFY(status == std::future_status::timeout); - auto const elapsed = steady_clock::now() - steady_begin; + auto const elapsed = steady_clock::now() - steady_start; + if (elapsed < seconds(1)) + std::cout << elapsed.count () << "ns < 1s" << std::endl; VERIFY(elapsed >= seconds(1)); VERIFY(elapsed < seconds(2)); } - // Wait for up to ~2s more + // Wait for up to ~4s more, but since the async sleep completes, the + // actual wait may be shorter than 1s. Tolerate 3s because 2s + // hasn't been enough in some extreme cases. { auto const steady_begin = steady_clock::now(); - auto const status = f1.wait_until(slow_start + milliseconds(300)); + auto const status = f1.wait_until(slow_start + milliseconds(500)); VERIFY(status == std::future_status::ready); auto const elapsed = steady_clock::now() - steady_begin; - VERIFY(elapsed < seconds(2)); + if (elapsed >= seconds(3)) + std::cout << elapsed.count () << "ns > 2s" << std::endl; + VERIFY(elapsed < seconds(3)); } }
reply other threads:[~2023-03-03 20:14 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20230303201419.335683858D28@sourceware.org \ --to=aoliva@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ --cc=libstdc++-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).