public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely@redhat.com>
To: Lewis Hyatt <lhyatt@gmail.com>
Cc: gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org
Subject: Re: [PATCH] libstdc++: testsuite: Address random failure in pthread_create() [PR54185]
Date: Tue, 18 Aug 2020 09:43:31 +0100	[thread overview]
Message-ID: <20200818084331.GD3400@redhat.com> (raw)
In-Reply-To: <20200813221536.GA51547@ldh-imac.local>

[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]

On 13/08/20 18:15 -0400, Lewis Hyatt via Libstdc++ wrote:
>Hello-
>
>The attached patch was discussed briefly on PR 54185 here:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54185#c14
>The test case for this PR sometimes fails due to random failures in
>pthread_create() that are not related to the original PR. This patch fixes
>it up by ignoring those failures. The test case was designed to repeat the
>same test 1000 times to attempt to reproduce a race condition, so I think is
>OK if some of those iterations are simply skipped.
>
>Thanks for taking a look at it; I can commit it if it makes sense.
>
>-Lewis

>libstdc++: testsuite: Address random failure in pthread_create() [PR54185]
>
>The test for this PR calls pthread_create() many times in a row, which may fail
>with EAGAIN sometimes. Avoid generating a test failure in this case.
>
>libstdc++-v3/ChangeLog:
>
>	PR libstdc++/54185
>	* testsuite/30_threads/condition_variable/54185.cc: Make test robust
>	to random pthread_create() failures.

Thanks for the patch. It certainly looks reasonable, but I wonder if
the attached version wouldn't be (very slightly) better. The
difference is that instead of just giving up at the first EAGAIN we
keep trying. This way we might be able to create a few more threads
before the loop finishes. If we still keep failing, it works the same.

I've also added a check that the failures are due to EAGAIN, and we'll
still terminate if there's some other problem. I'm assuming that your
failures are EAGAIN. Do you know why that's happening? Does your
system a low value for RLIMIT_NPROC or something?

The failures for that testcase on AIX appear to be different. It just
segfaults after destroying the condition_variable, which probably
means there's a POSIX conformance issue in AIX's pthread_cond_t.



[-- Attachment #2: patch.txt --]
[-- Type: text/x-patch, Size: 1586 bytes --]

diff --git a/libstdc++-v3/testsuite/30_threads/condition_variable/54185.cc b/libstdc++-v3/testsuite/30_threads/condition_variable/54185.cc
index ea0d5bb8740..8ccb79e6de6 100644
--- a/libstdc++-v3/testsuite/30_threads/condition_variable/54185.cc
+++ b/libstdc++-v3/testsuite/30_threads/condition_variable/54185.cc
@@ -31,31 +31,48 @@
 std::condition_variable* cond = nullptr;
 std::mutex mx;
 int started = 0;
+bool notified = false;
 int constexpr NUM_THREADS = 10;
 
-void do_thread_a()
+void do_thread_a(bool wait)
 {
   std::unique_lock<std::mutex> lock(mx);
-  if(++started >= NUM_THREADS)
+  if (++started >= NUM_THREADS)
   {
+    notified = true;
     cond->notify_all();
     delete cond;
     cond = nullptr;
   }
-  else
-    cond->wait(lock);
+  else if (wait)
+    cond->wait(lock, [] { return notified; });
 }
 
-int main(){
+int main()
+{
   std::vector<std::thread> vec;
-  for(int j = 0; j < 1000; ++j)
+  for (int j = 0; j < 1000; ++j)
   {
     started = 0;
+    notified = false;
     cond = new std::condition_variable;
     for (int i = 0; i < NUM_THREADS; ++i)
-      vec.emplace_back(&do_thread_a);
-    for (int i = 0; i < NUM_THREADS; ++i)
-      vec[i].join();
+      {
+	try
+	  {
+	    vec.emplace_back(&do_thread_a, true);
+	  }
+	catch(const std::system_error& e)
+	  {
+	    if (e.code() == std::errc::resource_unavailable_try_again)
+	      // Thread creation may fail due to resource limits; run serially.
+	      do_thread_a(false);
+	    else
+	      throw;
+	  }
+      }
+    for (auto& thread : vec)
+      thread.join();
     vec.clear();
   }
 }

  reply	other threads:[~2020-08-18  8:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-13 22:15 Lewis Hyatt
2020-08-18  8:43 ` Jonathan Wakely [this message]
2020-08-18 15:20   ` Lewis Hyatt
2020-08-18 18:15     ` Jonathan Wakely

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=20200818084331.GD3400@redhat.com \
    --to=jwakely@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=lhyatt@gmail.com \
    --cc=libstdc++@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: link
Be 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).