Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > multiple threads close, wait, join

Reply
Thread Tools

multiple threads close, wait, join

 
 
sam.n.seaborn@gmail.com
Guest
Posts: n/a
 
      07-21-2007

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 With Quote
 
 
 
 
Knute Johnson
Guest
Posts: n/a
 
      07-21-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) 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 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.

--

Knute Johnson
email s/nospam/knute/
 
Reply With Quote
 
 
 
 
Daniel Pitts
Guest
Posts: n/a
 
      07-22-2007
On Jul 21, 3:08 am, (E-Mail Removed) 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/>.

 
Reply With Quote
 
cyprian
Guest
Posts: n/a
 
      07-23-2007
On Jul 22, 3:44 am, Daniel Pitts <(E-Mail Removed)> wrote:
> On Jul 21, 3:08 am, (E-Mail Removed) 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/>.


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 With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
You must join New York Paid To Read !!!!!!! NewYork PTR is online!!! JOIN NOW!!!!!! Alan Silver ASP .Net 0 06-05-2006 03:27 PM
TB View, Threads, Threads with unread The Invisible Man Firefox 1 03-20-2006 02:09 AM
list.join()... re.join()...? Do they exist? (newbie questions...) googleboy Python 1 10-01-2005 12:56 PM
Standard Threads vs Weightless Threads yoda Python 2 08-01-2005 09:12 PM
running multiple threads and multiple processes at the same time Smegly C Programming 1 05-19-2004 02:59 AM



Advertisments