Hey, thanks Yoav.
Execution times are not significant because the code is not about performance. (It's full of Thread.sleep statements).
I am actually surprised that the test code runs on Solaris because I was under the impression that most JDKs on Unix had a bug causing the JVM to crash with 80 or more active treads with the following error:
#
# HotSpot Virtual Machine Error : 11
# Error ID : 4F530E43505002E6
# Please report this error at
# <http://java.sun.com/cgi-bin/bugreport.cgi>http://java.sun.com/cgi-bin/bugreport.cgi
This bug has been reported as #4724356.http://developer.java.sun.com/developer/bugParade/bugs/4724356.html
Anyway, the test code launches 125 threads so I thought it would crash under Solaris. (It crashes under Linux).
At 11:03 AM 6/5/2003 -0400, you wrote:
Howdy,
FYI: I've repeated the ReaderWriterLock test using JDK 1.3.1 and 1.4.1 on Solaris 8, with similar results. Tests passed, execution time was similar:
- 26:16 on JDK 1.4.1 Windows XP
- 24:41 on JDK 1.4.1 Solaris 8
- 27:21 on JDK 1.3.1 Solaris 8
But more importantly than the run time, the test ran without errors.
I have only one question, regarding the following from ReaderWriterLockTestCase:
public void test1() throws Exception { WLOOP = Long.parseLong(System.getProperty("runLen")); RLOOP = (long) (WLOOP * (1.0)); // readers loop longer
RLOOP is the same as the WLOOP: should the 1.0 factor be more, e.g. 1.5?
Good call.
The coefficient depends on many factors. On my machine 2.5 is the best value such that the writer threads and the readers threads finish the test more or less at the same time. A better method would have been to stop the reader threads when the writers finish.
Yoav Shapira Millennium ChemInformatics
--
Ceki For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
