Native Threads

Differences between Green Threads and Native Threads

• For purely sequential code, green threads are slightly faster than native threads.
  
  
• For multithreaded code that involves frequent synchronization, green threads are likely to be faster than native threads. Methods such as Object.notify() are much faster for green threads as compared to native threads.
  
  
• For multithreaded code with little synchronization and several runnable threads at a given time, only the native threads version will take advantage of a multiprocessor. It will be much faster as a result.
  
  
• Threads are timesliced correctly when using native threads. For green threads you can get that behavior by creating a high priority thread that wakes up regularly and immediately sleeps again, or you can use the -ts<time> option for time slicing. When using native threads, this is not necessary or useful.
  
  
• If you need to call pthreads library code, or call Java code from a pthread, you must use the native threads version. If the code involves lots of synchronization and not much true concurrency, it may run appreciably faster on a multiprocessor if you restrict it to a single processor with the IRIX runon command. (Synchronization across processors tends to be expensive.)

If your code runs differently under the two threads packages, check for thread-synchronization bugs in your code.

Caveats when using Native Threads

• Priorities are taken less seriously than with green threads. In easy cases, locks are implemented with spin locks. Code that relies on the highest priority thread not being interrupted is wrong in either case. It may happen to work with green threads; it is very likely to fail with native threads. (There is no reasonable way to make that assumption valid on a multiprocessor.)
  
  
• Garbage collection pauses tend to be longer with native threads because it takes longer to stop and restart threads. If garbage collection takes too much time, try increasing the heap size with the -ms and -mx flags. This will increase pause times, but will often greatly reduce their frequency, usually reducing overall execution time.
  
  
• Only a single Java VM may be created in an address space. If multiple threads in a pthread program need to invoke Java code, use AttachCurrentThread.
  
  
• Suspend, resume, and stop are deprecated and should be avoided, especially with native threads. They are implemented, but suspend and stop may not be acted upon as quickly as desired.
  
  
• The Java garbage collector uses pthread signals to stop some threads. This can be visible to native code called from Java, or to native code that has started a JVM in the same process. Although most system calls will be restarted if interrupted by a signal, such code should be prepared for the premature termination of a few pthread and/or system calls. Pthread code should always be prepared for the premature termination of condition variable waits, and the presence of a JVM makes that crucial. (This does not apply to Java's Object.wait().)

  The IRIX sleep() call and its variants may also terminate prematurely. To suspend a thread for a minimum amount of time, use either Java code or something like the following:

  int deep_sleep(int seconds)
  {
      time_t current, finish;
  
      current = time(0);
      finish = current + seconds;
      while (current < finish) {
          (void) sleep(finish - current);
          current = time(0);
      }
      return 0;
  }
  

System Requirements for Native Threads

If you plan to use the native threads subsystems, you will need to install some patches on your system; see Correctly Installing Java and Related Software..

Java and other Java-based names are trademarks of Sun Microsystems, Inc., and refer to Sun's family of Java-branded technologies. Sun, Sun Microsystems, and the Sun Logo are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries.