Java Threads scheduling: Determinitic?

From: Anne (anne_dolly00_at_yahoo.co.uk)
Date: 02/29/04

  • Next message: P Gentry: "Re: Java Threads scheduling: Determinitic?" 
    Date: 29 Feb 2004 07:27:57 -0800

    Heya,

    >From the following link:
    http://java.sun.com/docs/books/tutorial/essential/threads/priority.html
    It is said that:
    <<The Java runtime supports a very simple, deterministic scheduling
    algorithm known as fixed priority scheduling>>. The algorithms are
    particularly deterministic!

    The link includes two threads (of equal priority scheduling order)
    code.
    The run method for these two threads is
    public void run() {
        while (tick < 400000) {
            tick++;
            if ((tick % 50000) == 0)
                System.out.println("Thread #" + num
                                   + ", tick = " + tick);
        }
    }
    This run method contains a tight loop that increments the integer tick
    and every 50,000 ticks prints out the thread's identifier and its tick
    count.
    In execution on a time sliced operating systems,the output might look
    like:
    Thread #1, tick = 50000
    Thread #0, tick = 50000
    Thread #0, tick = 100000
    Thread #1, tick = 100000
    Thread #1, tick = 150000
    Thread #1, tick = 200000
    Thread #0, tick = 150000
    Thread #0, tick = 200000
    Thread #1, tick = 250000
    Thread #0, tick = 250000
    Thread #0, tick = 300000
    Thread #1, tick = 300000
    Thread #1, tick = 350000
    Thread #0, tick = 350000
    Thread #0, tick = 400000
    Thread #1, tick = 400000

    As mentioned in the article:
    << time-sliced system divides the CPU into time slots and iteratively
    gives each of the equal-and-highest priority threads a time slot in
    which to run. The time-sliced system iterates through the
    equal-and-highest priority threads, allowing each one a bit of time to
    run, until one or more of them finishes or until a higher priority
    thread preempts them.>>
    Then the article went on saying:
    <<Notice that time-slicing makes no guarantees as to how often or in
    what order threads are scheduled to run>>, altough the article claims
    (see above) that JRE supports deterministic scheduling algorithm!

    Personally,I can't understand from the above program output why some
    threads gets longer CPU quantum than others although they have the
    same priority and instantiates the same class, thus similar (CPU, I/O)
    dynamic utilisation.
    Since a time sliced OS uses a same time quantum value, and the above
    two threads moving through the same states [runnable, running,
    blocked],I expect that each thread will have similar CPU quantums
    number, and therefore the interleaving between the threads
    (instantiating the same class) should be regular, i.e. N successive
    CPU shots for thread1 then N successive CPU shots for thread 2, M
    successive CPU shots for thread1 then M successive CPU shots for
    thread 2, etc….which is not the case.
     
    Is there anything i am missing? is the issue related to how the JRE
    coordinates with the underlying OS? how , i really wonder?

    Besides, if we run the same program, we end up with different outputs;
    personally I expect only a possibe change on the threads order of
    execution.

    When running this program on a non-time-sliced system, however, you
    will see messages from one thread finish printing before the other
    thread ever gets a chance to print one message. Like this:
    Thread #0, tick = 50000
    Thread #0, tick = 100000
    Thread #0, tick = 150000
    Thread #0, tick = 200000
    Thread #0, tick = 250000
    Thread #0, tick = 300000
    Thread #0, tick = 350000
    Thread #0, tick = 400000
    Thread #1, tick = 50000
    Thread #1, tick = 100000
    Thread #1, tick = 150000
    Thread #1, tick = 200000
    Thread #1, tick = 250000
    Thread #1, tick = 300000
    Thread #1, tick = 350000
    Thread #1, tick = 400000

    Does it mean that System.println() is not a blocking system call. I
    was expecting the thread to move to a blocking state.

    Thanks for ur help

  • Next message: P Gentry: "Re: Java Threads scheduling: Determinitic?"

    Relevant Pages

    • Re: Lahman, how ya doing?
      ... >>>tick processing in a lower priority thread. ... >> I think I understand that in the context of the real controller. ... >> time is checked, and if a tick has passed, the low priority queue is ...
      (comp.object)
    • Re: Lahman, how ya doing?
      ... >>>done on some ticks in the real controller. ... >> I can imagine a high priority queue for analog peices whose evolution is ... and a low priority queue for delayable digital parts. ... >60 processing gets done in that tick but the 1 and 7 tick processing ...
      (comp.object)
    • Re: OEMGetRealTime and SoftRTC flag
      ... it's asking too much that there will be some default settings for ... Don't rule out that the tick count ISR is held off due to processing of an ... already running ISR. ... tick source) had the highest priority which seems no to be the case. ...
      (microsoft.public.windowsce.platbuilder)
    • Re: Need to run function every 20ms.
      ... CE is preemptive - a thread of higher priority will be scheduled if it need CPU at thenext tick or at an event which changes the run state. ... you can generate a system tick every 1mS. ...
      (microsoft.public.windowsce.embedded.vc)
    • Java Threads scheduling: Determinitic?
      ... algorithm known as fixed priority scheduling>>. ... The link includes two threads (of equal priority scheduling order) ... This run method contains a tight loop that increments the integer tick ... CPU shots for thread1 then N successive CPU shots for thread 2, ...
      (comp.os.linux.misc)