This is the mail archive of the
mailing list for the libstdc++ project.
Re: Regression test for thread safety?
- From: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- To: dkegel at ixiacom dot com
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Mon, 15 Jul 2002 23:07:32 -0500 (CDT)
- Subject: Re: Regression test for thread safety?
- Organization: Networks and Infrastructure Lab (IL02/2240), Motorola Labs
[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.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
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
Loren J. Rittle, Principal Staff Engineer, Motorola Labs (IL02/2240)
firstname.lastname@example.org, KeyID: 2048/ADCE34A5, FDC0292446937F2A240BC07D42763672