Re: Regression test for thread safety?

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

[OK, forgot to address this in my global thread-reply.]

> A monitor program might be able to do that automatically.

FYI, DejaGNU is such a monitor program.  Those tests usually run under
that environment.  By default, it will kill any test that runs for
over 5 minutes.

Also, please note that the thread tests only actually run under
DejaGNU on: *-*-freebsd* *-*-linux* *-*-solaris* *-*-cygwin

If that doesn't cover your target triple, then the test is only built.
The reason is that someone needs to update the tests in the obvious
way to add the correct per-system linking flag.  A patch that supports
your platform of interest would be acceptable.

> the data suggests running pthread5.cc, pthread6.cc, and pthread1.cc
> will be more effective than running pthread[234].cc.

Yes, white box analysis reveals that test 2 and 3 do not even test STL
locking primitives; they only test the spin-lock implementation as
used by string<>, etc.  Thus, defining _NOTHREADS could never have
caused test 2 or 3 to fail.  Test 1 only tests STL locking primitives.
Tests 4, 5 and 6 test both to some degree.  Test 4 stresses things
very lightly compared to, e.g., test 1 but it caught a particularly
nasty SMP issue in our sparc (and i386?) spin-lock implementation
and/or our reuse of it in libstdc++-v3.

Regarding how long some of the tests take to run: Without additional
comment (to avoid libel charges ;-), some systems appear to have
really lousy thread implementations when judged by these examples
(which, granted, are somewhat artificial in how real software will use
threads).

The iteration counters have already been scaled back due to a popular
system where it took "all day" to run them.  As currently published on
the gcc mainline, they all finish in under a minute (of CPU-time not
wall-time) on a certain OS, which only supports user-space threads,
running on commodity PII-350Mhz hardware:

    44r    22.5u     0.3s       pthread1.exe
    28r    13.2u     0.1s       pthread2.exe
    19r     8.8u     0.0s       pthread3.exe
    16r     6.9u     0.1s       pthread4.exe
   109r    51.4u     0.6s       pthread5.exe
   101r    44.7u     0.4s       pthread6.exe

Wall-time is greater than CPU-time since I had a 'gmake check' running
concurrently.

Regards,
Loren
-- 
Loren J. Rittle, Principal Staff Engineer, Motorola Labs (IL02/2240)
rittle@labs.mot.com, KeyID: 2048/ADCE34A5, FDC0292446937F2A240BC07D42763672