Re: Java Threads scheduling: Determinitic?

From: P Gentry (rdgentry1_at_cablelynx.com)
Date: 02/29/04

  • Next message: James Blackmore: "files ftp'd from VMS to Tru64 occasionally arrive as empty files ??" 
    Date: 29 Feb 2004 13:21:55 -0800

    anne_dolly00@yahoo.co.uk (Anne) wrote in message news:<cd6175dd.0402290727.10602888@posting.google.com>...
    > 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

    Of no specific knowledgeable help with your question but just happened
    to run into this 2 days ago. Perhaps it will be of interest to you.
    It discusses some shortcomings of the memory model spec and its
    effects on thread execution in some general terms.

    http://www-106.ibm.com/developerworks/library/j-jtp02244.html

    regards,
    prg
    email above disabled

  • Next message: James Blackmore: "files ftp'd from VMS to Tru64 occasionally arrive as empty files ??"

    Relevant Pages