[Prev] [Contents] [Next]

Mixing thread models or API sets

If you mix Pthread APIs with other threads management APIs that might be provided on the system, you could get your application into an unknown state. For example, Java or the IBM open class libraries threads implementations should not be used 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 may get unexpected results.

For example: Your 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 stores the posix thread handle for the thread. The native method then returns to java and continues to run normal java code in the JVM. Eventually, another java thread in your 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 Java's tendency to end the thread with a java exception may not be honored. Your application may not get the results that it expects. Do not manipulate threads from one thread model with APIs from another.

Another example: You may be allowed to manipulate the priorities of a Pthread using both pthread and AS/400 proprietary interfaces. If you do so, the priorities will always get set correctly. However; the priority returned from the Pthread interface pthread_getschedparam() will only be correct if setting the priority was always done using either the pthread_setschedparam() interface or some other interface, but not both. If multiple interfaces have been used to set the priority of the thread, pthread_getschedparam() will always return the priority set by the last pthread_setschedparam().



[Prev] [Contents] [Next]
Copyright © 1998, IBM Corporation. All rights reserved.
Comments? Contact
rchthrds@us.ibm.com