Cooperative threading preemptive threading - a bit confused

Discussion in 'Java' started by failure_to@yahoo.co.uk, Dec 27, 2007.

  1. Guest

    Hello

    I'm currently learning about threads and there are few things
    confusing about it

    1)

    If I understand it correctly, then in multithreaded program JVM
    obtains threads from the pool and manages which thread is run on CPU
    based on one of the two models:

    a) Cooperative threading model

    * here thread currently running voluntarily gives up control of the
    CPU ¡K thus if this running thread ¡§wanted ¡§, it could very well never
    give up the control of CPU?!
    * I¡¦m assuming thread priorities have no meaning when cooperative
    threading model is used?
    * Since it is a job of thread scheduler to decide which thread will
    run and how much time it will have „³ Thus what is its purpose when
    cooperative threading model is applied ( since here thread priorities
    have no meaning )?

    or

    b) Preemptive threading model:

    * Here OS interrupts threads after period of time?
    * Also, threads with higher priority can preempt lover priority
    threads ( assuming preempt means that lover thread is already running
    when higher priority thread decides it wants to run )?!
    * But even highest priority thread will only have so much time before
    the scheduler gives control ( even if just for a brief period of
    time ) to lover level priority thread?


    2)

    Is JVM always the one that manages thread movement ( by thread
    movement I mean deciding which thread to allow to run ), or are there
    OSs that either:

    a) won¡¦t allow JVM to take control of managing threads?

    b) or some JVM version for particular OS allows this OS to do the job
    of thread movement instead of JVM?

    c) What kind of thread movement model do these OSs usually employ?


    thank you
    , Dec 27, 2007
    #1
    1. Advertising

  2. Mark Space Guest

    wrote:

    > * here thread currently running voluntarily gives up control of the
    > CPU ¡K thus if this running thread ¡§wanted ¡§, it could very well never
    > give up the control of CPU?!


    I only know a few things about the possible thread models used by JVMs
    and OSs, but yes, as I understand, an errant or malicious thread can
    refuse to reliquish CPU control.

    > * I¡¦m assuming thread priorities have no meaning when cooperative
    > threading model is used?


    I'd assume the thread scheduled to run is selected on the basis of
    priority (all other things being equal). Priority does not allow you to
    preempt another running thread though. No preemption means no preemption.

    > * Since it is a job of thread scheduler to decide which thread will
    > run and how much time it will have „³ Thus what is its purpose when
    > cooperative threading model is applied ( since here thread priorities
    > have no meaning )?


    The purpose of cooperative threading is small environments where the
    hardware needed to implement preemption is not available.


    > b) Preemptive threading model:
    >
    > * Here OS interrupts threads after period of time?


    Usually, or more often a running thread will make an IO call, block, and
    another thread will be scheduled. Most processes are IO bound.

    > * Also, threads with higher priority can preempt lover priority
    > threads ( assuming preempt means that lover thread is already running
    > when higher priority thread decides it wants to run )?!


    I'd assume so. Note that this can be bad, resulting in deadlock and
    livelock. Also priority inversion effects are possible.

    > * But even highest priority thread will only have so much time before
    > the scheduler gives control ( even if just for a brief period of
    > time ) to lover level priority thread?


    I would not assume this. Some schedulers work this way, but simpler
    ones may not. Assume the worst. If running a high priority process
    will mess you up, assume it will run. If having a higher priority
    process uninterrupted by a lower one will mess you up, assume that
    happens too.


    > a) won¡¦t allow JVM to take control of managing threads?


    I dunno about "won't allow." I assume there can be environments where
    the JVM can't manage threads as it would really like. Most OS allow
    some kind of creation and scheduling of threads. I can see the JVM
    using the OS instead of it's own algorithm.

    >
    > b) or some JVM version for particular OS allows this OS to do the job
    > of thread movement instead of JVM?


    This would be the normal case, I expect.

    >
    > c) What kind of thread movement model do these OSs usually employ?


    Some kind of round-robin + priority schemes. Best to actually read up
    if you have serious concerns.
    Mark Space, Dec 28, 2007
    #2
    1. Advertising

  3. Karl Guest

    <> wrote in message
    news:...
    > Hello
    >
    > I'm currently learning about threads and there are few things
    > confusing about it
    >
    > 1)
    >
    > If I understand it correctly, then in multithreaded program JVM
    > obtains threads from the pool and manages which thread is run on CPU
    > based on one of the two models:
    >
    > a) Cooperative threading model
    >
    > * here thread currently running voluntarily gives up control of the
    > CPU ¡K thus if this running thread ¡§wanted ¡§, it could very well never
    > give up the control of CPU?!
    > * I¡¦m assuming thread priorities have no meaning when cooperative
    > threading model is used?
    > * Since it is a job of thread scheduler to decide which thread will
    > run and how much time it will have „³ Thus what is its purpose when
    > cooperative threading model is applied ( since here thread priorities
    > have no meaning )?
    >
    > or
    >
    > b) Preemptive threading model:
    >
    > * Here OS interrupts threads after period of time?
    > * Also, threads with higher priority can preempt lover priority
    > threads ( assuming preempt means that lover thread is already running
    > when higher priority thread decides it wants to run )?!
    > * But even highest priority thread will only have so much time before
    > the scheduler gives control ( even if just for a brief period of
    > time ) to lover level priority thread?
    >
    >
    > 2)
    >
    > Is JVM always the one that manages thread movement ( by thread
    > movement I mean deciding which thread to allow to run ), or are there
    > OSs that either:
    >
    > a) won¡¦t allow JVM to take control of managing threads?
    >
    > b) or some JVM version for particular OS allows this OS to do the job
    > of thread movement instead of JVM?
    >
    > c) What kind of thread movement model do these OSs usually employ?
    >
    >
    > thank you


    This link describes the interaction between the Java VM and the Solaris
    threading model: http://java.sun.com/docs/hotspot/threads/threads.html
    This link describes the Windows .net WPF threading model, which I suspect is
    somewhat analogous to the Swing threading model, but definitely not the same
    thing: http://msdn2.microsoft.com/en-us/library/ms741870.aspx
    I could not readily find anything about the raw Windows 32 or Windows 64
    threading model API (it used to be widely discussed). The JVM tends to use
    the platform threading model if there is one, although there are options in
    some cases. I seem to recall that we had the option of using "green" threads
    or "native" threads on certain Linux platforms:
    http://en.wikipedia.org/wiki/Green_threads
    Karl, Dec 28, 2007
    #3
  4. Lew Guest

    Karl wrote:
    > This link describes the interaction between the Java VM and the Solaris
    > threading model: http://java.sun.com/docs/hotspot/threads/threads.html
    > This link describes the Windows .net WPF threading model, which I suspect is
    > somewhat analogous to the Swing threading model, but definitely not the same
    > thing: http://msdn2.microsoft.com/en-us/library/ms741870.aspx
    > I could not readily find anything about the raw Windows 32 or Windows 64
    > threading model API (it used to be widely discussed). The JVM tends to use
    > the platform threading model if there is one, although there are options in
    > some cases. I seem to recall that we had the option of using "green" threads
    > or "native" threads on certain Linux platforms:
    > http://en.wikipedia.org/wiki/Green_threads


    Linux implementations will use native threads if the conditions are right.

    Different platforms support multi-threaded applications to different degrees.
    Just as Java was designed from the beginning to support multi-threaded
    applications, so an operating system like Solaris was designed fundamentally
    to work with multiple-processor, multiple-thread hardware. Linux went through
    an evolution in its approach to threads. Systems themselves have changed from
    single-core, single-threaded single-processor boards to multi-core,
    multi-threaded, multi-processor configurations. Java tends to exploit
    whatever the platform makes available.

    Bear in mind also that there are JVMs from many makers, and many versions
    thereof from each, of varying capability with respect to threads.

    --
    Lew
    Lew, Dec 28, 2007
    #4
  5. Karl Guest

    "Lew" <> wrote in message
    news:...
    > Karl wrote:
    >> This link describes the interaction between the Java VM and the Solaris
    >> threading model: http://java.sun.com/docs/hotspot/threads/threads.html
    >> This link describes the Windows .net WPF threading model, which I suspect
    >> is somewhat analogous to the Swing threading model, but definitely not
    >> the same thing: http://msdn2.microsoft.com/en-us/library/ms741870.aspx
    >> I could not readily find anything about the raw Windows 32 or Windows 64
    >> threading model API (it used to be widely discussed). The JVM tends to
    >> use the platform threading model if there is one, although there are
    >> options in some cases. I seem to recall that we had the option of using
    >> "green" threads or "native" threads on certain Linux platforms:
    >> http://en.wikipedia.org/wiki/Green_threads

    >
    > Linux implementations will use native threads if the conditions are right.
    >
    > Different platforms support multi-threaded applications to different
    > degrees. Just as Java was designed from the beginning to support
    > multi-threaded applications, so an operating system like Solaris was
    > designed fundamentally to work with multiple-processor, multiple-thread
    > hardware. Linux went through an evolution in its approach to threads.
    > Systems themselves have changed from single-core, single-threaded
    > single-processor boards to multi-core, multi-threaded, multi-processor
    > configurations. Java tends to exploit whatever the platform makes
    > available.


    One would hope that the VM would make platform dependencies and/or
    capabilities an abstraction.

    > Bear in mind also that there are JVMs from many makers, and many versions
    > thereof from each, of varying capability with respect to threads.


    One would hope that the VM specification would sufficiently constrain the
    variations such that developers in most cases could write to the Java
    threading model, and not be concerned about the platform. Are there any
    articles or white papers describing specific situations where this is not
    the case?

    I can see advantages to providing the ability in the VM to use
    platform-specific extensions for specialized applications, where the
    developer makes a conscious decision to do so.
    Karl, Dec 28, 2007
    #5
  6. Mark Space Guest

    Karl wrote:

    > One would hope that the VM specification would sufficiently constrain the
    > variations such that developers in most cases could write to the Java
    > threading model, and not be concerned about the platform. Are there any
    > articles or white papers describing specific situations where this is not
    > the case?


    Yes, even basic books mention this. Learning Java by O'Reilly mentions
    that not all JVM support preemptive multitasking. The JLS does the
    opposite of what you hope. It pushes the responsibility for using
    threads correctly in all environments onto the programmer. The JLS spec
    on threads is a lot less defined than you are assuming.

    http://java.sun.com/docs/books/jls/third_edition/html/memory.html

    Now I haven't read all of that, because I haven't had to deal with
    complicated multi-thread apps yet, but at least I know it exists and
    where to find it.
    Mark Space, Dec 28, 2007
    #6
  7. On Dec 28, 12:12 pm, Mark Space <> wrote:
    > Karl wrote:
    > > One would hope that the VM specification would sufficiently constrain the
    > > variations such that developers in most cases could write to the Java
    > > threading model, and not be concerned about the platform. Are there any
    > > articles or white papers describing specific situations where this is not
    > > the case?

    >
    > Yes, even basic books mention this.  Learning Java by O'Reilly mentions
    > that not all JVM support preemptive multitasking.  The JLS does the
    > opposite of what you hope.  It pushes the responsibility for using
    > threads correctly in all environments onto the programmer.  The JLS spec
    > on threads is a lot less defined than you are assuming.
    >
    > http://java.sun.com/docs/books/jls/third_edition/html/memory.html
    >
    > Now I haven't read all of that, because I haven't had to deal with
    > complicated multi-thread apps yet, but at least I know it exists and
    > where to find it.


    In particular, it is a valid Java VM implementation that, when a new
    thread is started, runs only the new thread until it terminates or
    until it blocks while synchronizing on a monitor.
    Owen Jacobson, Dec 28, 2007
    #7
  8. Karl Guest

    "Mark Space" <> wrote in message
    news:5Ncdj.33005$...
    > Karl wrote:
    >
    >> One would hope that the VM specification would sufficiently constrain the
    >> variations such that developers in most cases could write to the Java
    >> threading model, and not be concerned about the platform. Are there any
    >> articles or white papers describing specific situations where this is not
    >> the case?

    >
    > Yes, even basic books mention this. Learning Java by O'Reilly mentions
    > that not all JVM support preemptive multitasking. The JLS does the
    > opposite of what you hope. It pushes the responsibility for using threads
    > correctly in all environments onto the programmer. The JLS spec on
    > threads is a lot less defined than you are assuming.
    >
    > http://java.sun.com/docs/books/jls/third_edition/html/memory.html
    >
    > Now I haven't read all of that, because I haven't had to deal with
    > complicated multi-thread apps yet, but at least I know it exists and where
    > to find it.


    Fascinating. I have been programming professionally in Java for about 10
    years now, so I do not read the "basic books" very much anymore. Perhaps it
    is time for a refresher course ;-)

    In my early Java days (JDK 1.1), if I ever encountered write-ups on these
    issues, I must have failed to take notice. That being said, I have written
    some massively scalable server applications that run under Windows, Solaris
    and Linux, and except for having to specify green threads to make things
    work in Linux, I can recall no platform-specific threading problems. These
    applications involve lots of network and file I/O and general data
    processing.

    The only thing I can conclude from that is that I must either (a) have an
    innate sense of how to use threads "correctly" (whatever that means across
    platforms), or (b) I have simply lucked into designs that just happen to
    work on all three platforms. Perhaps a combination of the two, but I don't
    want to give myself too much credit here.

    I have rarely had the need to go beyond the simple "synchronized" block and
    wait/notify constructs. In the entire time between JDK 1.1 and JDK 1.5, I
    think I was obliged to hand-code one mutex. Since JDK 1.5, I have rarely
    needed to dip into the concurrency packages, even while continuing to be
    called upon to produce heavily concurrent, multi-threaded applications.
    Furthermore, I have few UI problems as long as I adhere to the Swing
    threading model design patterns.

    Just my experience with the Java threading API.
    Karl, Dec 28, 2007
    #8
  9. Guest

    hello


    >> b) Preemptive threading model:
    >> Here OS interrupts threads after period of time?

    >Usually, or more often a running thread will make an IO call,
    >block, and another thread will be scheduled. Most processes are
    >IO bound.
    >


    So in cases where running thread doesn't have IO call, or block or
    sleep()... thus running thread is happily executing its code and not
    just "sitting" there, then in these cases JVM ( assuming, scheduler is
    not too simple ) will simply do context switch due to this thread
    already running for some time? But if running thread has IO call, or
    calls sleep() etc, then JVM will notice that and let some other thread
    run for awhile?


    >>But even highest priority thread will only have so much time
    >>before the scheduler gives control ( even if just for a brief
    >>period of time ) to lover level priority thread?

    >I would not assume this. Some schedulers work this way, but
    >simpler ones may not.


    Are we talking about OS or JVM schedulers or both( since there are
    prob many versions of JVM schedulers also )?


    thanx
    , Dec 28, 2007
    #9
  10. Mark Space Guest

    wrote:

    > So in cases where running thread doesn't have IO call, or block or
    > sleep()... thus running thread is happily executing its code and not
    > just "sitting" there, then in these cases JVM ( assuming, scheduler is
    > not too simple ) will simply do context switch due to this thread
    > already running for some time? But if running thread has IO call, or


    As Karl pointed out, if you're not running green threads on a Linux
    machine, it seems possible that one thread will NOT be context-switched
    even if it has been running for a very long time. Some IO is
    non-blocking, so even that may not context-switch a thread.


    > Are we talking about OS or JVM schedulers or both( since there are
    > prob many versions of JVM schedulers also )?



    Exactly. Any JVM can implement it's own or use the OS scheduler. Some
    like Linux appear to do both.
    Mark Space, Dec 29, 2007
    #10
    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. ker chee huar
    Replies:
    1
    Views:
    521
    Hermit Dave
    Jan 13, 2004
  2. Dan Perl
    Replies:
    4
    Views:
    275
    Dan Perl
    Dec 3, 2004
  3. John Salerno

    preemptive OOP?

    John Salerno, Sep 28, 2006, in forum: Python
    Replies:
    15
    Views:
    474
    Mark Elston
    Oct 4, 2006
  4. Hendrik Maryns

    Confused: Java6 32-bit vs. 64-bit

    Hendrik Maryns, May 2, 2007, in forum: Java
    Replies:
    3
    Views:
    571
    Tom Hawtin
    May 2, 2007
  5. Akihiro KAYAMA

    fiber(cooperative multi-threading)

    Akihiro KAYAMA, Dec 22, 2007, in forum: Python
    Replies:
    17
    Views:
    615
    Bjoern Schliessmann
    Dec 28, 2007
Loading...

Share This Page