multiple threads close, wait, join

Discussion in 'Java' started by sam.n.seaborn@gmail.com, Jul 21, 2007.

  1. Guest

    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
     
    , Jul 21, 2007
    #1
    1. Advertising

  2. 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/
     
    Knute Johnson, Jul 21, 2007
    #2
    1. Advertising

  3. Daniel Pitts Guest

    On Jul 21, 3:08 am, 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/>.
     
    Daniel Pitts, Jul 22, 2007
    #3
  4. cyprian Guest

    On Jul 22, 3:44 am, Daniel Pitts <> wrote:
    > On Jul 21, 3:08 am, 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.
     
    cyprian, Jul 23, 2007
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Gary J
    Replies:
    19
    Views:
    39,367
    Chris Uppal
    Aug 31, 2004
  2. Alan Silver
    Replies:
    0
    Views:
    907
    Alan Silver
    Jun 5, 2006
  3. Huey

    How to make "fork/wait" to WAIT longer?

    Huey, Mar 1, 2004, in forum: C Programming
    Replies:
    1
    Views:
    1,992
    -berlin.de
    Mar 1, 2004
  4. googleboy
    Replies:
    1
    Views:
    947
    Benji York
    Oct 1, 2005
  5. Iñaki Baz Castillo
    Replies:
    7
    Views:
    921
    Iñaki Baz Castillo
    Jan 12, 2010
Loading...

Share This Page