A daemon[1] thread is normal in every respect save one. When it is time for the JVM to decide if
it's time to exit (based on whether there are any active threads), daemons are ignored. Thus if you
have ten daemon threads running and your last normal thread exits, the JVM will exit the entire
process.
[1]
A few years ago, one very conservative (and not very savvy) religious group called for a
nationwide prayer meeting to cast out the "demons" that were in UNIX.
Daemons are used for background tasks that make sense only when there are other threads that are
doing the real work. The garbage collector is an excellent example of a proper use of daemons.
You can set the daemon flag on or off as your program requires with thread.setDaemon(),
but you can only do this before you call start(). You cannot change the status of a running
thread. You can also check the status of a thread with isDaemon().
You will probably never use daemons.
Daemon Thread Groups
A daemon thread group is normal in every respect save one. When it becomes empty, it may
automatically be destroyed and removed from its parent. There is no relationship between daemon
threads and daemon thread groups. You can change the daemon status of a thread group at any
time.
Calling Native Code
From Java you can use the JNI (Java Native Interface) library to call C, C++, etc., code from your
Java program, or to call Java code from your C, C++, etc., code. If your Java program is
multithreaded, calling native code from multiple threads does not change the issues of thread
safety at all. If the native code uses data that is shared by multiple threads, that data must be
properly protected. By far the simplest and most reliable method of doing this is to have your Java
code take care of the locking.
If a Java method calls a native function, which in turn uses some shared data, synchronizing the
method properly will ensure that said data is protected properly. Don't worry, be happy!
If for some reason this is not an option (perhaps the native code accesses different bits of data
under different circumstances which Java cannot know about, and you want those different bits of
data to be accessible concurrently), you have a challenge in front of you. The JNI spec specifies
how native threads and locks will interact with Java code. If you're using a native threads library
underneath Java, you'll probably be OK using the native locks. If you're using green threads, on
the other hand, you're in trouble. Green threads will not interact with native locks in any viable
fashion.
If you are running Java with the native threads library, most things work as you would expect,
even though they are not necessarily clearly specified. A native method can be declared
synchronized just like a non-native method. In addition, within the native method the C code can
call wait(), notify(), etc., it is necessary to make explicit JNI calls back into Java. They are
not supported directly as with monitors.] Moreover, MonitorEnter() is recursive (as you
Search WWH :
