JVM in Java is responsible to create a Non-Daemon Thread when executing a Java program. Is it correct?
If so, who is responsible to create Daemon Threads in Java?
Programmers and JVM both create Non-Daemon Threads? Is it correct?
Looking for a clear explanation.
Thanks in Advance.
It doesn’t matter whether “the JVM” or “the programmer” started a thread. A thread is a daemon thread when setDaemon(true) has been called on it before starting or a daemon thread created the thread without calling setDaemon. That’s it.
The documentation of Thread also says:
When a Java Virtual Machine starts up, there is usually a single non-daemon thread (which typically calls the method named main of some designated class).
There is no responsibility to create daemon threads. Marking a thread as daemon has only one implication which the documentation continues to explain:
The Java Virtual Machine continues to execute threads until either of the following occurs:
The exit method of class Runtime has been called and the security manager has permitted the exit operation to take place.
All threads that are not daemon threads have died, either by returning from the call to the run method or by throwing an exception that propagates beyond the run method.
So, that’s the only implication; the existence of a non-daemon thread may prevent the JVM from terminating automatically, whereas threads marked as daemon do not.
Related
Each Tomcat server runs on its own JVM and each JVM is a separate process in Operating System. Now I have deployed multiple application in Tomcat which has it own context and own Class Loaders. And if I run multiple Thread in each of this application, how Operating system handles this Thread switching and how entire JVM as process is switched with other process. How these JVM process and Java threads are related in terms of context switching. How it works in most of latest operating system.
In Linux threads are implemented mostly the same way as the processes. So scheduler doesn't care much about processes, it switches between threads instead. Read here more low level explanation.
Now JVM is a process which typically has a lot of threads. Each one of them is mapped one to one to some linux process. In that case scheduler will assign timeslaces(time for run for a particular thread) regardless what process(JVM in your case) owns this thread. This means if one JVM has ten times more threads in total than the other JVM, then the first JVM still has more time consuming CPU than the other one.
You can affect this behaviour in a different number of ways.
You can change scheduler algorithm in your OS
You can change priority of a particular thread. In that case it will get more time than other threads within the same JVM and threads from other JVM. You can assing priority both through java and linux terminal (nice command)
You can bind a particular thread to some set of CPUs. Use taskset command. Each thread has its own PID which you can get with help of jstack utility(bundled with JDK)
Does a thread that is blocked cause the process to become blocked? Why and How? Thanks to all experts for answering.
A process cannot be blocked because the concept of "blocked" only applies to a thread of execution. The only meaningful sense in which you could say that a process was blocked is if the process only had one thread and that thread was blocked.
A thread is a flow of execution through the process code, with its own program counter, system registers and stack. A thread is also called a light weight process. Threads provide a way to improve application performance through parallelism. Threads represent a software approach to improving performance of operating system by reducing the overhead thread is equivalent to a classical process.
Each thread belongs to exactly one process and no thread can exist outside a process. Each thread represents a separate flow of control.Threads have been successfully used in implementing network servers and web server. They also provide a suitable foundation for parallel execution of applications on shared memory multiprocessors.
So, as you may have guessed, No ! A thread cannot block a process.
I have found an application which requests process information using wmi queries (all threads and more info on each thread). I modified this application to determine the CPU usage per thread.
(if my application is called 'appy', then the threads are named 'appy/0', 'appy/1', ...)
My question: is there a way to easily identify these threads outside of an IDE or another debugging environment?
I know there is the NameThreadForDebugging method, but this isn't accessible outside the debugging environment.
Is there a way to assign your own thread id upon creating that thread?
Or is the only way to know who is who (the threads) by creating a dictionary and write that dictionary to a file so it is externally accessible.
Thanks in advance!
No, you cannot assign your own thread ID, the thread ID is assigned to a thread by the CreateThread function and cannot be changed during its lifetime. And as you said the only way to identify thread in the external application (not a debugger) is to share the thread identification with that application somehow.
However it's not necessary to share the information through a file, you can use a shared memory block for instance. It will be much more efficient than using files.
As the reference about thread ID you can take the remark by the GetCurrentThreadId function:
Until the thread terminates, the thread identifier uniquely identifies
the thread throughout the system.
I am new to linux and writing a service in C++ which spawns multiple threads and I am starting the service by calling it from init.d, but how should I send the terminate signal to my application from the script , so that my service terminates all the threads and exits.
And also where can I find the source code for any linux services. e.g. /etc.init.d/rc5.d/S14cron . It will be helpful in understanding how to implement a service.
The classic reference for this kind of question is Steven's "Advanced Programming in the UNIX Environment". You can find the source code to this text book here.
Depends what your application does.
Personally I'd keep a thread just for handling signals and call sigprocmask in the other threads to stop signals being delivered to them.
The main thread / signal handling thread (it is usually a good idea to make this the main thread) can then send a message to its threads to tell them to finish what they're doing and quit.
Alternatively, if you like the principle of crash-only, you could just call exit_group and be done with it :)
Is it possible that a program which does not kill its threads properly before exiting still be running some piece of code somewhere even though it has been killed in system monitor? I am running ubuntu in a non virtual environment. My application is made with QT, it contains QThreads, a main thread and concurent functions.
If you kill the process then you kill all its threads. The only cause for concern would be if your application had spawned multiple processes - if that is the case then you may still have code executing on the machine.
This is all very speculative though as I don't know what operating system you code is running on, whether or not your application runs in a virtual environment, etc. Environment-specific factors are very relevant to the discussion, can you share a bit more about your application?
It is not possible, all modern heaviliy used operating systems manage these resources quite tightly. Threads cannot run without a process... They are all brantches from the original thread.
I don't know of any OS that doesn't fully terminate all it's threads when you kill the processes, it's possible to spawn child processes that live on after the main process has exited but in the case of threads i'd say it's not possible.