This program records times for various fine-grained synchronization
schemes, and provides some ways of measuring them over different
context parameters.
Quick start:
- javac -d base of some CLASSPATH *.java
You'll need Swing (JFC). (This
program currently imports the javax.swing versions.
You can edit imports to instead use other versions.)
- java EDU.oswego.cs.dl.util.concurrent.misc.SynchronizationTimer
- Click start.
Clicking stop cancels the run. Cancellation can take
a while when there are a lot of threads.
- For more explanation about tested classes, see
Documentation for util.concurrent
Synchronization schemes are tested around implementations and
subclasses of
RNG
, which is just a hacked random
number generator class. Objects of this class have just enough
state and require just enough computation to be reasonable minimal
targets. (Additionally, random numbers are needed a lot in these
kinds of time tests, so basing them on objects that produce random
numbers is convenient.) Computation of each random number is
padded a bit with an adjustable compute loop running a random
number of times to avoid getting schedulers locked into
uninteresting patterns.
Each iteration of each test ultimately somehow calls
the random number generation
method of an RNG. The time listed is the average time it took to do
one iteration, in microseconds. These are just based on wallclock
time (System.currentTimeMillis()). Thread
construction time is
NOT included in these times.
In tests with many threads, construction and other bookkeeping
can take longer than the tests themselves.
Results are listed in a table, and optionally printed on standard output.
You can redirect standard output to save to a file.
The total amount of ``real'' computation reported in each cell is
the same. Thus, the unobtainably ideal pattern of results would be
for every cell of the table to be the same (and very small).
A thread pool (PooledExecutor) is used to manage the threads used in
test runs. The current number of active threads is indicated in
the panel. It should normally be at most three plus the number of threads used in the
indicated test column (there are at most three overhead threads per run), although
it may transiently climb, and is larger in those tests that
generate their own internal threads (for example ThreadedExceutor). If the
indicated size fails to return to zero within about 10 seconds of
either hitting stop
or the end of a run, you may have a
problem with interruption handling on your Java VM.
This program cannot
tell you how busy your computer is while running tests.
You can run a utility program (for
example
perfmeter
or
top
on unix)
alongside this program
to find out.
A number of control parameters can be changed at any time.
Most combinations of parameter settings create contexts
that are completely unrepresentative of those seen in practical
applications. However, they can be set to provide rough analogs of
real applications, and the results used as rough guesses about
performance impact. Also, do not be too upset about slow
performance on tests representing situations
that would never occur in practice.
You can control parameters by clicking any of the following,
at any time. (You can even change parameters
while tests are running, in which case they will take
effect as soon as possible. Most controls momentarily stall
while test objects and threads are being constructed, to avoid
inconsistencies during test runs.)
To scaffold all this, the RNG class is defined in
layers. Each RNG has internal non-public methods that do the actual
computation, and public methods that call the internal ones. The
particular classes run in tests might change over time, but
currently includes the following general kinds:
Sync
The test code is ugly; it has just evolved over the years. Sorry.