I was asked :
of examples of user-space-threaded systems and
kernel-space-threaded systems.
whether Native POSIX Thread Library is considered part of user-space
or kernel-space.
and if Java threading is done in user-space.
there's a huge amount of information about all these topics, but there doesn't seem to be a direct answer to those specific questions. I hope you could help me.
I am using the terminology set out in this Wikipedia page
https://en.wikipedia.org/wiki/Thread_(computing).
(I'll leave it to you to figure out if that terminology matches your Arabic course curriculum.)
Q1: Provide examples of user-space-threaded systems and kernel-space-threaded systems.
Modern Linux systems support kernel threads.
Old Linux and old Unix systems didn't support kernel threads, so if you needed threading you have to implemented it entirely in user space. The old Java "green threads" model was an example of threads implemented entirely in user space.
Q2: Is Native POSIX Thread Library is considered part of user-space or kernel-space.
The Native POSIX Thread Library (NPTL) is actually an API. It could be implemented in many ways.
Typical implementations (e.g. current Linux ones) use kernel threads; i.e. there is a 1:1 mapping between a "user-space" thread abstraction, and "kernel-space" threads or Light Weight Processes managed by the kernel.
Q3: Is Java threading is done in user-space.
Not in modern Java implementations. The first JVM implementations used user-space threads (aka green threads).
Note that there is debate over the true meaning of "user-space" and "kernel" thread, and how pthreads and NPTL fits into the taxonomy; see Is Pthread library actually a user thread solution?.
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.