ibm-information-center/dist/eclipse/plugins/i5OS.ic.apis_5.4.0.1/concept5.htm

70 lines
3.4 KiB
HTML

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Copyright" content="Copyright (c) 2006 by IBM Corporation">
<title>Mixing thread models or API setse</title>
<!-- Begin Header Records ========================================== -->
<!-- All rights reserved. Licensed Materials Property of IBM -->
<!-- US Government Users Restricted Rights -->
<!-- Use, duplication or disclosure restricted by -->
<!-- GSA ADP Schedule Contract with IBM Corp. -->
<!-- Change History: -->
<!-- YYMMDD USERID Change description -->
<!-- NETMG2 SCRIPT A converted by B2H R4.1 (346) (CMS) by HOLTJM at -->
<!-- RCHVMW2 on 29 Jan 1999 at 10:01:37 -->
<!--File Edited November 2001 -->
<!--End Header Records -->
<link rel="stylesheet" type="text/css" href="../rzahg/ic.css">
</head>
<body>
<!-- Java sync-link -->
<script language="Javascript" src="../rzahg/synch.js" type="text/javascript">
</script>
<h2>Mixing thread models or API sets</h2>
<p>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.</p>
<p>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 <strong>pthread_self</strong>() 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
<strong>pthread_cancel</strong>(). 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.</p>
<p>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 <strong>
pthread_getschedparam</strong>() is only correct if the priority was always set
using either the <strong>pthread_setschedparam</strong>() interface or another
interface, but not both. If multiple interfaces have been used to set the
priority of the thread, <strong>pthread_getschedparam</strong>() always returns
the priority set by the last <strong>pthread_setschedparam</strong>().</p>
<hr>
<center>
<table cellpadding="2" cellspacing="2">
<tr align="center">
<td valign="middle" align="center">
<a href="rzah4mst.htm">Pthread APIs</a> |
<a href="aplist.htm">APIs by category</a></td>
</tr>
</table>
</center>
</body>
</html>