[libstdc++ PATCH/RFC] problem with pthread4 testcase

[Loren James Rittle]

> The "pthread4" test seems to make the following assumptions:
>
>	1. Test is being run on a multiprocessor, and thus the two
>	   threads will run concurrently.
>
> -- or --
>
>	2. If not run on a multiprocessor, that the threads will be
>	   time-sliced against each other, thus creating the illusion
>	   of concurrency.

3. It was assumed that modern thread implementations have a
   non-portable call to force time-sliced behavior, if needed by the
   application code.  However, being non-portable; we couldn't
   foresee what code would be required when people ported
   the almost portable pthread tests to new machines.

pthread4.cc was designed to find a rather horrible error on (you
guessed it) an SMP machine.  Now, on some non-MP machines, it was
possible to force time-sliced behavior (with a no-portable call).  To
wit, this code early in main():

	#if defined(__sun) && defined(__svr4__)
	  pthread_setconcurrency (2);
	#endif

All pthread[1-6].cc tests have some form of that code.

It was expected that any implementation that required non-portable
stuff to allow concurrency to occur would have a similar construct
available.  Some non-MP thread implementations support concurrency
without needing any such calls (FreeBSD 4, Linux, OSF1).

> #2 is a bogus assumption; POSIX does not specify the behavior of the
> thread scheduler.

I don't disagree with your statement about POSIX but...

NetBSD has a *brand new* thread implementation designed for deployment
in 2002 that doesn't even support concurrency on a single processor
machine with a special setup call?  Are you pulling my leg?

According to a paper by Nathan J. Williams (of Wasabi Systems, Inc ;-),
_An Implementation of Scheduler Activations on the NetBSD Operating
System_, section 6, paragraph 2, I believe that this implementation
fully supports time-sliced round-robin scheduling "if requested by the
application".  Please find out what few calls are required to make
that happen.

Sorry the tests had no comment near the area where you enable the test
for new hosts re the assumptions.  Perhaps in pthread1.cc, we could
add some form of 1, 2 and 3 above.

> This bogus assumption causes this test to fall over with NetBSD's new
> threads library on a uniprocessor.  Since the producer never does anything
> which would cause it to block, the consumer never gets a chance to run.

Yup, I see the busy loop formed when conditions are ripe.

> The following patch makes the test work for me, but I fear that it might
> defeat the testcase.  I suppose one option is to yield only if __NetBSD__
> is defined, or to simply not run the test for *-*-netbsd* ... however,
> I see value in keeping this test for *-*-netbsd*, so I'd prefer not to
> skip it.

If you need explicit yields, the test cases are quite pointless.  It
is important to find a way to run all tests with concurrency on single
processor machines if possible.  Otherwise, you are not testing the
C++ library code in a manner we expected it to work for end-users of
systems that support concurrency.

Thanks,
Loren