If you mix Pthread APIs with other threads management APIs that might be provided on the system, your application can enter an unknown state. For example, you should not use Java or the IBM open class libraries threads implementations to manipulate a thread that was created using the Pthread APIs. Similarly, if you use a Pthread API like pthread_cancel() on a thread created and managed by the JVM, you can get unexpected results.
The following example demonstrates this problem. A Java application creates several Java threads. One Java thread runs normally and eventually calls a native method. The native method uses the pthread_self() API to store the POSIX thread handle for the thread. The native method then returns to Java and continues to run normal Java code in the Java virtual machine (JVM). Eventually, another Java thread in the application calls a native method. The new native method uses the stored POSIX thread handle in a call to pthread_cancel(). This causes cause the Java thread to be terminated with Pthread semantics. The Java thread cleanup requirements or the tendency of Java to end the thread with a Java exception may not be honored. The application may not get the results that you expect. Do not manipulate threads from one thread model with APIs from another.
The following example also demonstrates this problem. The priorities of a Pthread may sometimes be manipulated using both Pthread and iSeries proprietary interfaces. If they are manipulated, the priorities are always set correctly; however the priority returned from the Pthread interface pthread_getschedparam() is only correct if the priority was always set using either the pthread_setschedparam() interface or another interface, but not both. If multiple interfaces have been used to set the priority of the thread, pthread_getschedparam() always returns the priority set by the last pthread_setschedparam().
| Pthread APIs | APIs by category |