Re: testsuite/pthread4.cc and linux

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

In article <20030514141003.74cfdbbc.bkoz@redhat.com> Benjamin writes:

> The fourth thread test, phtread4.cc, rarely (never?) passes on my
> various x86/linux machines.

> However, it does pass for others: [many other linux and non-linux]

> Why is this?

Well, I see that I didn't do a great job of bringing that test case
into our suite...  ;-)

> Does this have something to do with --enable-threads=posix at configure
> time? Usually I don't configure with this, because I didn't think it was
> needed. I tried configuring in much the same way as the ia64/x86 tests
> that pass, and I still get failures.

Agreed, this should not matter, esp. for linux, since you get
--enable-threads=posix unless you explicitly disable threads.

> Possible solutions to this might include:

> 1) [...] 2) [...]

3) I do note that there is one aspect to this test that might utterly
kill performance on some thread implementations (POSIX doesn't mandate
much about the scheduler itself; and there are many strategies that
are quite valid and all good user-level code should use explicit
condition signaling not busy loops, as it was, or random yields, as it
was when I first got it; I implemented the standard high/low watermark
halt/signal here).

As committed to mainline (Benjamin, please move to 3.3 after you
verified that it helped in context and reopened).  I ran with various
gcc versions on various platforms and noted 2x-3x speedup as expected
(even for an optimally-fair, time-based scheduler, I'd expect this
code to have done at least twice the extra work required)...  If your
platform still fails this test and/or takes a really long time after
this patch, then we have a real issue to debug (i.e. a principle of
the platform/thread implementation should care about this issue).

Thanks for the report,
Loren

	* testsuite/thread/pthread4.cc: Tweak test.

Index: libstdc++-v3/testsuite/thread/pthread4.cc
===================================================================
RCS file: /cvs/gcc/gcc/libstdc++-v3/testsuite/thread/pthread4.cc,v
retrieving revision 1.5
diff -c -r1.5 pthread4.cc
*** libstdc++-v3/testsuite/thread/pthread4.cc	15 Apr 2003 20:31:57 -0000	1.5
--- libstdc++-v3/testsuite/thread/pthread4.cc	15 May 2003 01:58:03 -0000
***************
*** 35,40 ****
--- 35,42 ----
  
  static list<string> foo;
  static pthread_mutex_t fooLock = PTHREAD_MUTEX_INITIALIZER;
+ static pthread_cond_t fooCondOverflow = PTHREAD_COND_INITIALIZER;
+ static pthread_cond_t fooCondUnderflow = PTHREAD_COND_INITIALIZER;
  static unsigned max_size = 10;
  #if defined(__CYGWIN__)
  static int iters = 10000;
***************
*** 50,60 ****
        string str ("test string");
  
        pthread_mutex_lock (&fooLock);
!       if (foo.size () < max_size)
! 	{
! 	  foo.push_back (str);
! 	  num++;
! 	}
        pthread_mutex_unlock (&fooLock);
      }
  
--- 52,63 ----
        string str ("test string");
  
        pthread_mutex_lock (&fooLock);
!       while (foo.size () >= max_size)
! 	pthread_cond_wait (&fooCondOverflow, &fooLock);
!       foo.push_back (str);
!       num++;
!       if (foo.size () >= (max_size / 2))
! 	pthread_cond_signal (&fooCondUnderflow);
        pthread_mutex_unlock (&fooLock);
      }
  
***************
*** 67,78 ****
--- 70,84 ----
    for (int num = 0; num < iters; )
      {
        pthread_mutex_lock (&fooLock);
+       while (foo.size () == 0)
+ 	pthread_cond_wait (&fooCondUnderflow, &fooLock);
        while (foo.size () > 0)
  	{
  	  string str = foo.back ();
  	  foo.pop_back ();
  	  num++;
  	}
+       pthread_cond_signal (&fooCondOverflow);
        pthread_mutex_unlock (&fooLock);
      }