What is the difference between threads in java and native threads?
Java threads can be implemented in any way that conforms to the specification. The specification doesn't require a specific implementation.
Effectively all modern desktop and/or server JVMs implement Java threads as native threads. That means that there is exactly 1 native thread for each Java thread and that the operating system does all the scheduling, just as it does for a C program, for example.
Some old JVMs and possibly some JVMs for devices with limited resources might implement threads in a way where the number of native threads used is smaller than the number of Java threads running (or possibly 1). Those implementations are said to implement so called "green threads". In this case the JVM itself is responsible for task switching and scheduling, as opposed to delegating that task to the operating system.
It depends on the implementation of the JVM, of course, but I think they are the same. It is, a Thread in Java is implemented via a native thread. You can expect/do with Java threads all kind of things you can with native threads.
Java threads and Native threads are completely different. Native thread is part of underlying platform (the OS).
Java threads are one of the feature of Java Language for supporting concurrency. Java specification controls API and functioning of Java threads. Ultimately Java threads will be mapped to native threads during execution of the java program.
Also java threads needn't get one to one mapped with native threads.
Java Threads (Thread class and Runnable interface) are a much higher-level API than native threads in memory-shared applications. I recommended this book "Java Threads" by Oaks and Wong http://shop.oreilly.com/product/9780596007829.do. It's common practice to implement the Runnable interface, but it depends on your code scope.
Related
What I know is after JDK 1.2 all Java Threads are created using 'Native Thread Model' which associates each Java Thread with an OS thread with the help of JNI and OS Thread library.
So from the following text I believe that all Java threads created nowadays can realize use of multi-core processors:
Multiple native threads can coexist. Therefore it is also called many-to-many model. Such characteristic of this model allows it to take complete advantage of multi-core processors and execute threads on separate individual cores concurrently.
But when I read about the introduction of Fork/Join Framework introduced in JDK 7 in JAVA The Compelete Reference :
Although the original concurrent API was impressive in its own right, it was significantly expanded by JDK 7. The most important addition was the Fork/Join Framework. The Fork/Join Framework facilitates the creation of programs that make use of multiple processors (such as those found in multicore systems). Thus, it streamlines the development of programs in which two or more pieces execute with true simultaneity (that is, true parallel execution), not just time-slicing.
It makes me question why the framework was introduced when 'Java Native Thread Model' existed since JDK 3?
Fork join framework does not replace the original low level thread API; it makes it easier to use for certain classes of problems.
The original, low-level thread API works: you can use all the CPUs and all the cores on the CPUs installed on the system. If you ever try to actually write multithreaded applications, you'll quickly realize that it is hard.
The low level thread API works well for problems where threads are largely independent, and don't have to share information between each other - in other words, embarrassingly parallel problems. Many problems however are not like this. With the low level API, it is very difficult to implement complex algorithms in a way that is safe (produces correct results and does not have unwanted effects like dead lock) and efficient (does not waste system resources).
The Java fork/join framework, an implementation on the fork/join model, was created as a high level mechanism to make it easier to apply parallel computing for divide and conquer algorithms.
Recently, I came to know about the Java 7 fork/join framework - what I learned is that it could be useful for divide-and-conquer like problems.
My question is, does the framework guarantees executing threads on separate CPUs? Or is it event possible to instruct the threads I create using classes of concurrent package to run on separate CPUs available in my server?
It'll be built upon the standard JVM concurrency primitives, in which case they will (eventually) be scheduled onto real OS threads. You cannot guarantee that your OS scheduler is going to schedule threads onto separate CPUS, although it's quite likely in most instances.
Trying to guess what a concurrent scheduler is going to do at runtime is a really bad idea. Just assume that you will be able to make use of no more than as many CPUs as you have active threads, and don't try to second-guess the runtime behaviour unless you're trying to do a particular kind of very low-level optimisation.
At least it will do its best. The fork/join framework is designed to take advantage of multiple processors. By default ForkJoinPool is created with the number of worker threads equal to the number of processors.
Does the framework guarantee executing threads on separate CPUs?
No. No guarantees.
Or is it event possible to instruct the threads I create using classes of concurrent package to run on separate CPUs available in my server?
Not using the standard Java libraries. In theory, anything is possible (up to the limit of what the OS allows) if you are willing to dig around in the native layers of the JVM. But you will be in for a lot of unnecessary work / pain.
My advice:
You probably don't need that level of control. (IMO) it is likely that the default behaviour of the native thread scheduler is "good enough" to achieve satisfactory performance.
If you really need that level of control, you would be better off using a different programming language; i.e. one where you can interact directly with the host OS'es native thread scheduler. You may even need a different operating system ...
As for as I know, Java threads can communicate using some thread APIs. But I want to know how the Java threads and the OS threads are communicting with each other. For example a Java thread needs to wait for some OS thread finishes its execution and returns some results to this Java thread and it process the same.
Many mix up threads and processes here, the jvm is a process which may spawn more threads. Threads are lighter processes which share memory within their process. A process on the other hand lives in his own address space, which makes the context switch more expensive. You can communicate between different processes via the IPC mechanisms provided by your OS and you can communicate between different threads within the same process due to shared memory and other techniques. What you can't is communicate from ThreadA(ProcessA) to ThreadA(ProcessB) without going through plain old IPC: ThreadA(ProcessA) -> ProcessA -> IPC(OS) -> ProcessB -> ThreadA(ProcessB)).
You can use RMI to communicate between two java processes, if you want to "talk" to native OS processes, you have to go JNI to call the IPC mechanisms your OS of choice provides imo.
Feel free to correct me here :)
Sidenote:
You cant see the threads of your JVM with a process manager (as long as your JVM does not map threads to native processes, which would be stupid but possible), you need to use jps and jstack to do that.
Every Instance of JVM is essentially an OS process.
Java threads usually but don't necessarily run on native threads and Java concurrency classes could but don't necessarily map onto native equivalents.
If you had to sync between a native thread and a Java thread, you will most likely have to consider writing a JNI method that your Java thread calls. This JNI method would do whatever native synchronization operation it needs to do and then return. Every platform is going to do this differently but I assume this wouldn't be too much of an issue if you need to inspect native threads in the first place.
Would it be possible to implement a custom Thread class in Java (using JNI) in a safe / correct way?
Suppose I write my own NewThread class, with a native start() method, which forks the execution, calls run() in the forked thread and returns...
Is that possible? Would the JVM complain? Is it "legal" according to the specs? Would this break anything, like, in the memory-model? Does it depend on the particular JVM?
Your questions is answered in the Java Native Interface
Programmer's Guide and Specification, section 8.1.5.
The important issue is that the VM has to use the same thread model as you are in your native code. Some of the first Java VMs used so called "green threads" on some operating systems (Linux) to emulate thread context switching, since the operating system itself didn't offer native threading support. These "green threads" would not be able to interact with native threads, if you would use one of these old VMs on a newer operating system version with native thread support.
Since Sun's JRE 1.3, I think all "normal" VMs are using native threads directly, which means that you can use native threads yourself in JNI code and expect everything to work as you expect.
It is possible. In the past I was using a C++ lib that read messages for the socket. After the initialization through JNI the library started a couple of pthreads that read data from the socket and did calls in the Java realm through JNI. The said pthreads where venturing pretty deep into the Java code. The only problems we had were memory issue on the JNI seam. After reading the JNI docs and some debugging the issues where solved. So, no problems with memory model.
Don't know if JVM will trigger JIT based on executions incoming from JNI, so could be a performance hit there.
Doable, tricky in places. If you can do with Java Threads, avoid this. I know I would.
I understand that the jvm is itself an application that turns the bytecode of the java executable into native machine code, but when using native threads I have some questions that I just cannot seem to answer.
Does every thread create their own
instance of the jvm to handle their
particular execution?
If not then does the jvm have to have some way to schedule which thread it will handle next, if so wouldn't this render the multi-threaded nature of java useless since only one thread can be ran at a time?
Does every thread create their own instance of the JVM to handle their particular execution?
No. They execute in the same JVM so that (for example) they can share objects and values of static fields.
If not then does the JVM have to have some way to schedule which thread it will handle next
There are two kinds of thread implementation in Java. Native threads are mapped onto a thread abstraction which is implemented by the host OS. The OS takes care of native thread scheduling, and time slicing.
The second kind of thread is "green threads". These are implemented and managed by the JVM itself, with the JVM implementing thread scheduling. Java green thread implementations have not been supported by Sun / Oracle JVMs since Java 1.2. (See Green Threads vs Non Green Threads)
If so wouldn't this render the multi-threaded nature of Java useless since only one thread can be ran at a time?
We are talking about green threads now, and this is of historic interest (only) from the Java perspective.
Green threads have the advantage that scheduling and context switching are faster in the non-I/O case. (Based on measurements made with Java on Linux 2.2; http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.8.9238)
With pure green threads, N programming language threads are mapped to a single native thread. In this model you don't get true parallel execution, as you noted.
In a hybrid thread implementation, N programming language threads are mapped onto M native threads (where N > M). In this model, the in-process thread scheduler is responsible for the green thread to native thread scheduling AND you get true parallel execution (if M > 1); see https://stackoverflow.com/a/16965741/139985.
But even with the pure green threads, you still get concurrency. Control is switched to another threads a thread blocks on an I/O operation, whick acquiring a lock, and so on. Furthermore, the JVM's runtime could implement periodic thread preemption so that a CPU intensive thread doesn't monopolize the (single) core to the exclusion of other threads
Does every thread create their own instance of the jvm to handle their particular execution?
No, your application running in the JVM can have many threads that all exist within that instance of the JVM.
If not then does the jvm have to have some way to schedule which thread it will handle next...
Yes, the JVM has a thread scheduler. There are many different algorithms for thread scheduling, and which one is used is JVM-vendor dependent. (Scheduling in general is an interesting topic.)
...if so wouldn't this render the multi-threaded nature of java useless since only one thread can be ran at a time?
I'm not sure I understand this part of your question. This is kind of the point of threading. You typically have more threads than CPUs, and you want to run more than one thing at a time. Threading allows you to take full(er) advantage of your CPU by making sure it's busy processing one thread while another is waiting on I/O, or is for some other reason not busy.
A Java thread may be mapped one-to-one to a kernel thread. But this must not be so. There could be n kernel threads running m java threads, where m may be much larger than n, and n should be larger than the number of processors. The JVM itself starts the n kernel threads, and each one of them picks a java thread and runs it for a while, then switches to some other java thread. The operating system picks kernel threads and assigns them to a cpu. So there may be thread scheduling on several levels.
You may be interested to look at the GO programming language, where thousands of so called "Goroutines" are run by dozens of threads.
Java threads are mapped to native OS threads. They have little to do with the JVM itself.