While I was going through a book "The Complete Reference Java Ninth Edition", I come to know about a fact related to context switching in java threads.
Following is the excerpt:
In cases where two threads with the same priority are competing for CPU cycles, the
situation is a bit complicated. For operating systems such as Windows, threads of equal
priority are time-sliced automatically in round-robin fashion. For other types of operating
systems, threads of equal priority must voluntarily yield control to their peers. If they don’t,
the other threads will not run.
And a Caution to this :
CAUTION Portability problems can arise from the differences in the way that operating systems
context-switch threads of equal priority
I was wondering if there is any way to avoid the problems related to portability in above cases.
If I test my multithreaded code on windows and deploy it on Unix in production, would I be in trouble ?
Please correct me if my understanding is not perfect.
This text doesn't really say very much. It says "For operating systems such as Windows" but it doesn't specify which operating systems it considers "such as" Windows. I consider the text in the book misleading and not very useful in 2018.
In the earliest versions of Java, it was true that on most Unix-like operating systems, it was using "Green threads" which had this property.
Java has been using native threads on Linux for a very, very long time, so at this time, Linux should be considered "such as Windows" in this sense.
But the Java VM specification and the Java Language specifications do not guarantee pre-emptive threads, so it's still possible to make a JVM that is compliant with the specifications that doesn't have pre-emptive threads at the same priority. I don't know of any JVM implementations that are like that, however.
By the way, you didn't specify what type of "Unix" you were referring to, and you didn't specify which vendor/version of the JVM you were using - to give a 100% correct answer, you need to give that information.
Related
I am really curious about how the JVM works with threads!
In my searches on the internet, I found some material about RTSJ, but I don't know if it's the right directions for my answers.
Can someone give me directions, material, articles or suggestions about the JVM scheduling algorithm?
I am also looking for information about the default configuration of Java threads in the scheduler, like how long does it take for every thread in case of time-slicing.
I appreciate any help, thank you!
There is no single Java Virtual Machine; JVM is a specification, and there are multiple implementations of it, including the OpenJDK version and the Sun version of it, among others. I don't know for certain, but I would guess that any reasonable JVM would simply use the underlying threading mechanism provided by the OS, which would imply POSIX Threads (pthreads) on UNIX (Mac OS X, Linux, etc.) and would imply WIN32 threads on Windows. Typically, those systems use a round-robin strategy by default.
It doesn't. The JVM uses operating system native threads, so the OS does the scheduling, not the JVM.
A while ago I wrote some articles on thread scheduling from the point of view of Java. However, on mainstream platforms, threading behaviour essentially depends on underlying OS threading.
Have a look in particular at my page on what is Java thread priority, which explains how Java's priority levels map to underlying OS threading priorities, and how in practice this makes threads of different priorities behave on Linux vs Windows. A major difference discussed is that under Linux there's more of a relationship between thread priority and the proportion of CPU allocated to a thread, whereas under Windows this isn't directly the case (see the graphs).
I don't have commenting rights so writing is here...
JVM invokes pthreads(generally used threading mechanism,other variants are there) for each corresponding request. But the scheduling here is done entirely by OS acting as host.
But it is a preferred approach and it is possible to schedule these threads by JVM. For example in Jikes RVM there are options to override this approach of OS decision. For example, in it threads are referred as RVMThread and they can be scheduled/manipulated using org.jikesrvm.schedular package classes.
For more reference
I have learnt while studying operating system concepts that there are two types of Threads : Kernel level and User level.
I also learnt that Kernel level threads or processes can be executed in multiprocessor environments too.
I have basic doubt regarding Java threads (being user level threads),
can we use them to execute in multiprocessor environment ?
First the answer is yes. You can make use of your multi-core processors' full power by creating multiple threads in java.
According to what I know, jvm employs a mixed thread model including both kernel threads and user threads. It has a strategy to decide when to create which type of threads. I believe that when the system resource is abundant, it will tends to create kernel thread and assign java thread object to run on it.
Sounds to me like you are talking about the good old Java 1.1 “green threads”. This was a kludge for operating system’s not having a native thread support, or at least no stable support. This feature does not exist in current JVM implementations any more, at least when talking about the reference implementation from Oracle. Java threads are always kernel threads on these JVMs.
So the answer is, yes, Java threads will benefit from SMP aka Multicore CPUs. It requires the operating system to have a native thread implementation, but without it the entire SMP machine would not make much sense. And the JVM must be able to use it, which is the case in all common systems.
As what I know, Java is using operating system threads (in contrast to i.e. Erlang), that means that the threads created with Java on Windows and Linux may behave different.
Are there any differences on Java threads on Windows and Linux? What is the biggest difference? It's maybe only a difference in performance?
This is a very general question, so I'll give a general answer.
Java switched from green threads, to native threads early in its development. This does not mean that threads created on Windows and Linux will behave differently as both platforms will utilize native threads in their respective JVM implementations.
The thread interface exposed to Java by each OS, and similarly the native interfaces to threading via pthreads and Windows threads are very similar.
The biggest differences with respect to threading on the two platforms are that all threads on Linux are a form of process. Windows treats threads and processes very differently.
In my personal experience, native threads on Windows are slightly more lightweight and may perform slightly better within single process applications. Correspondingly (and perhaps irrelevant), are that Windows processes are extremely heavyweight compared with their Linux counterparts.
JVM hide all OS differences to you...
as was previously answered the threads on windows are big heavyweight that linux ones.
by experience a heavy multi threading application could have some delays with automatic memory garbage collector and those can generate huge memory peaks.
I have already used thread in both OS, and no differences for the java developer.
:)
I am really curious about how the JVM works with threads!
In my searches on the internet, I found some material about RTSJ, but I don't know if it's the right directions for my answers.
Can someone give me directions, material, articles or suggestions about the JVM scheduling algorithm?
I am also looking for information about the default configuration of Java threads in the scheduler, like how long does it take for every thread in case of time-slicing.
I appreciate any help, thank you!
There is no single Java Virtual Machine; JVM is a specification, and there are multiple implementations of it, including the OpenJDK version and the Sun version of it, among others. I don't know for certain, but I would guess that any reasonable JVM would simply use the underlying threading mechanism provided by the OS, which would imply POSIX Threads (pthreads) on UNIX (Mac OS X, Linux, etc.) and would imply WIN32 threads on Windows. Typically, those systems use a round-robin strategy by default.
It doesn't. The JVM uses operating system native threads, so the OS does the scheduling, not the JVM.
A while ago I wrote some articles on thread scheduling from the point of view of Java. However, on mainstream platforms, threading behaviour essentially depends on underlying OS threading.
Have a look in particular at my page on what is Java thread priority, which explains how Java's priority levels map to underlying OS threading priorities, and how in practice this makes threads of different priorities behave on Linux vs Windows. A major difference discussed is that under Linux there's more of a relationship between thread priority and the proportion of CPU allocated to a thread, whereas under Windows this isn't directly the case (see the graphs).
I don't have commenting rights so writing is here...
JVM invokes pthreads(generally used threading mechanism,other variants are there) for each corresponding request. But the scheduling here is done entirely by OS acting as host.
But it is a preferred approach and it is possible to schedule these threads by JVM. For example in Jikes RVM there are options to override this approach of OS decision. For example, in it threads are referred as RVMThread and they can be scheduled/manipulated using org.jikesrvm.schedular package classes.
For more reference
When I create a multi-threaded program and I use methods such as Wait or Signal to control threads among other things, does JVM control all the thread state changes or does the underlying OS have anything to do with it.
It depends on the implementation of the JVM. Most modern JVM's (Suns HotSpot, Oracles JRockit, IBM VMs) will use the Operating system threading model as this will give the best performance.
Early implementations used green threads - The VM was modelling the threads using itself. This was typically used when the platform or operating system it was running on didn't support threading. For example, in Java 1.1, Green Threads were used on Solaris. At the time, the common pattern to use multiple cores/CPU's in Solaris was to use multiple processes - only later were threads added to the Operating System.
The Java Language Specification does not specify how Threads must be implemented but in general, if the OS has threading support, modern JVM's will use the OS implementation. When there is no support in the OS, for example on low end mobile phones or in a Java Card implementation for example, then Green Threads will be used by the runtime.
In general, Java threads will map to OS threads and Java will make use of OS synchronisation primitives to implement synchronized/wait/signal/..., but the mapping is not as straightforward as you might think. In fact, the JVM uses some clever tricks to improve performance and implements as much of the synchronisation code itself (at least the uncontended case).
If you are really interested in the details, have a look at the JVM source code or at cmeerw.org/notes/java_sync.html which provides some overview of how Java's synchronisation primitives are implemented on Linux and Solaris.
In the early days of linux 2.4, at least the IBM JVM used separate processes to implement java threads. This resulted in a long time to switch between threads, as the system needed to activate a completely different process each time.