«

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

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.

<> wrote in message
news:79d4ca15-6187-454e-ad88-...
> 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 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" <> 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 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/t...ml/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.

On Dec 28, 12:12*pm, Mark Space <marksp...@sbc.global.net> 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/t...ml/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.

"Mark Space" <> wrote in message
news:5Ncdj.33005$ et...
> 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/t...ml/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.

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

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.