Re: multiple threads close, wait, join
On Jul 21, 3:08 am, sam.n.seab...@gmail.com wrote:
Hello,
I am writing a world clock in Java. The basic requirements are:
Input is a list of time zones e.g. EST, NZ, UTC
clock ticks on and at the end of each second, prints out 1 line per
time zone
e.g
UTC: 9:50:00 AM
EDT: 5:50:00 AM
NZST: 9:50:00 PM
---
UTC: 9:50:01 AM
EDT: 5:50:01 AM
NZST: 9:50:01 PM
My questions (mostly for my own edification, hopefully useful to other
readers too):
1. I'm thinking of using one thread for each timezone. Prevailing
wisdom seems to indicate that multiple threads, i.e. more than 2X on a
machine with X processors, is generally not useful for performance.
But my idea is this. Each thread (timezone) can sleep(1000)
independently so that at the end of each second of wall-clock-time,
the display can be in relative sync. (This is a simple clock, not
looking for atomic precision.) The question is: does this design sound
sensible or is it just easier to have a single thread sleep for a
second and loop through the time zones and print them out?
2. The next version will be graphical i.e. visualize a simple GUI with
one pane (or graphical equivalent) per time zone that gets refreshed
somewhat synchronously. There's obviously a wealth of material on
designing this sort of thing (I have googled quite a bit about this).
My question is: is there a focused article or tutorial that talks
about how several graphical panes (or windows or whatever) can be
updated simultaneously? How does the multi-thread design affect this?
I'm thinking that each thread can drive its own pane and still
maintain synchronization.
TIA!
Sam N Seaborn
I would say that all timezones are relative to each other, and that
you only really need one "clock", to notify when you need to update.
For the text based version, you can even use java.util.Timer, instead
of dealing with Thread.sleep yourself. And for the graphical version,
you could use javax.swing.Timer, and have your timer simply tell your
clocks to repaint. The each "clock" should be its own component, and
it should override the paintComponent method to draw the actual clock,
based on the current time appropriate for the timezone.
This eliminates the need to handle multiple threads almost completely,
and inexperienced use of threading/synchronizing is cause too many
bugs. Specifically, Swing is designed to be SINGLE THREADED, you are
never supposed to interact with a Swing based object on any thread
except the Event Dispatch Thread.
Whatever approach you take, I strongly suggest at least reading the
sun tutorial: <http://java.sun.com/docs/books/tutorial/uiswing/
concurrency/index.html>
After that, I also suggest getting and reading the book "Java
Concurrency In Practice" <http://www.javaconcurrencyinpractice.com/>.