multiple threads close, wait, join

Thread view:

sam.n.seaborn@gmail.com - 21 Jul 2007 11:08 GMT

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

Reply to this Message

Knute Johnson - 21 Jul 2007 16:21 GMT

> Hello,
>
[quoted text clipped - 37 lines]
>
> Sam N Seaborn

I would think that you would want all the clocks to update at the same
instant. In that case I would use one timer and write your list of
times or update the graphics of all clocks at the same time. It will be
more difficult to synchronize the actions of multiple thread than a
single thread or timer.

Signature

Knute Johnson
email s/nospam/knute/

Reply to this Message

Daniel Pitts - 22 Jul 2007 02:44 GMT

On Jul 21, 3:08 am, sam.n.seab...@gmail.com wrote:

> Hello,
>
[quoted text clipped - 37 lines]
>
> 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/>.

Reply to this Message

cyprian - 23 Jul 2007 12:06 GMT

> On Jul 21, 3:08 am, sam.n.seab...@gmail.com wrote:
>
[quoted text clipped - 60 lines]
> After that, I also suggest getting and reading the book "Java
> Concurrency In Practice" <http://www.javaconcurrencyinpractice.com/>.

1. create a central thread, the utc timezone thread.
2. Create an edt thread whose parent is the utc thread, getXXX()
methods come here that convert utc to edt
3. Create an nzst thread whose parent is the edt thread, converting to
specifics as appropriate.
4. When utc thread is stopped, it sends a signal that reverberates
through the chain.
Why: that way locking on any timer thread is avoided and
synchronization differs not according to lock but according to machine
variations because all the threads have the same priority. when utc
thread is stopped, all other threads get stopped automatically. this
is just a plan of action. itching to implement it myself.
question really intriguing.

Reply to this Message

multiple threads close, wait, join

Free Magazines