Ideally (not required, but desirable) I would like to have the post,
wait and read section uninterrupted.
I'm not sure I understand the underlying requirement. If the post, wait,
and read cannot be interrupted, then you can only be running one query
thread at once, so why multithreaded? Unless perhaps you are farming
off the processing of results to another thread.
You can synchronise on an object to enforce a critical section. Threads
that don't synchronise on it can interrupt, but your application code
at least can be made to behave. If you define your qeury wait get method
as something like
public synchronized void queryWaitAndGetMethod()
{
qeury();
wait();
get();
}
and have lots of threads running that in a loop, then only one can be
in that method at once.
An alternate is to pick a synchronisation object somewhere and
// some code, in some method somewhere, and suddenly a critical
// section
synchronized (MY_OBJECT)
{
// the critical section
}
It is a concern though that you're holding a lock during a wait. You are
forcing the system to do no useful work at that time. Ideally critical
sections should be kept as small as possible. I like to defer even
things like using the Java Logging API until outside my critical
section:
int iResult;
synchronized (this)
{
iResult = doSomethingQuickly();
}
LOGGER.log(Level.FINE, "MY_MESSAGE_KEY", new Integer(iResult));
If load testing is what you're after, then you'd want other threads to
be able to occur at the same time. You're taking advantage of the fact
that most of your time is going to be in the waiting stage, and your
code can be doing some interesting other work, like firing off another
query, when it would otherwise be doing nothing. For load testing, you
hope that your test processes take longer to run out of resources than
the thing they're testing.
If you want to run your tests one after the other, then run them all
in one thread in a loop. If result processing is hard work, then save
results until later, or pass them off to another thread. You can use
thread prioritisation to try to manage where your resources go. If its
the handling of your result getting being interrupted that worries you,
then prioritisation may be what you're after.
For handing results to other threads, Java 1.4 provides a between-thread
message queue mechanism out of the box (too late for us, as I
wrote my own LimitedLengthQueue for Java 1.2 or 1.3). Your worker
threads post their results to the queue, and your result processing
thread pulls them off asynchronously and processes them. You can use
SwingUtilities.invokeLater() if you're wanting to display a real time
result graph or something, though I'd not want to see that directly in
the worker threads.
A last word. Beware deadlocking. Best way - trying not to lock two or
more things at once is one way of avoiding it. If a critical section (A)
calls a method that may itself lock something different (B). Make sure
that nothing that method can call will try to lock A, otherwise someone
entering directly at B can deadlock with you.
- Richard
