Java Threads Issues

This section discusses Java-generic and Solaris-specific issues that might be of concern if you are writing Java applications for the Solaris product.

Generic Java Issues

Numerous methods have been deprecated for JDK 1.1. Refer to Table 4-1 for a complete list.

Solaris-Specific Issues

Some issues are specific to Solaris, as explained in the following sections.

Using Multithreading-Unsafe Libraries

This workaround is not trivial and can cause deadlocks if not carefully programmed. Do this only if absolutely unavoidable.

If you try to run a multithreaded Java application that also uses native C/C++ code with previously-released libraries that have not been compiled with the -D_REENTRANT flag on, you could encounter problems, as explained here.

With a native-threaded JVM such as 1.1, libc stores system call error code in a thread-specific errno. When an mt-unsafe library references errno, it references the global version, because it was not compiled with the -D_REENTRANT flag on. Therefore, the library can't access the thread-specific errno and its errno-dependent response to a failed system call would be incorrect.

The real solution is to ensure that an MT Java application that also uses native code by way of native methods is linked with MT-safe (or at least errno--safe libraries).

However, if you cannot avoid referencing errno-unsafe libraries, the following workaround can help: Enable the main thread to enter the Java application and arrange for all calls to the unsafe library to be routed through the main thread. For example, if a thread makes a JNI call, the JVM can marshal all JNI arguments and put them in a queue serviced by the main thread. The thread can wait for the main thread to issue the call and return the results to it.

It is not necessary for calls made from only the main thread to the unsafe library to go through a lock, since calls to the library are single-threaded through the library; only the main thread ever calls the library. The main thread could issue non-blocking calls, and so forth, to ensure some amount of concurrency. The main thread's errno is global, and the same errno would be referenced by both libc and the MT-unsafe library.

interrupt() Method

The use of this method is generally discouraged; it is not currently specified as particularly useful. The Java Language Specification (JLS) defines it as a way to interrupt a target thread only if and when it calls the wait() method.

However, on the Solaris platform, the semantics have been extended so that it also interrupts the target thread's I/O calls. Do not depend on this extension, as it might be discontinued. Additionally, using the extended, I/O interruption semantics of the interrupt method makes the code non-portable across different JVMs.

Thread Priorities

The thread priorities available to Java threads on a native threaded JVM should be treated as hints to the scheduler, especially if the threads are compute-bound. The number of processors available to a process is dynamic and unpredictable. Therefore, an attempt to use priorities to schedule execution on any multi-tasked, multiprocessor system is not likely to succeed.