HP NonStop G-Series - Manual (Page 83)

strcpy (svcinfo->outString, "Return from SIMPVIEW");
svcinfo->outInt = 100;
svcinfo->outFloat = (float) 100.00;
/*
* If there was an error, return TPFAIL
* tpreturn(TPFAIL, ErrorCode, (char *)svcinfo, sizeof (*svcinfo), 0);
*/
tpreturn(TPSUCCESS, 0, (char *)svcinfo, sizeof (*svcinfo), 0);
}
Multithreaded Applications
As a Java based set of classes, Jolt supports multithreaded applications. However, various implementations of the Java language differ
with respect to certain language and environment features. Jolt programmers need to be aware of the following:
The use of preemptive and non-preemptive threads when creating applications or applets with the Jolt Class Library. ●
The use of threads to get asynchronous behavior similar to the tpacall() function in TUXEDO. ●
The following section describes the issues arising from using threads with different Java implementations and is followed by an example
of the use of threads in a Jolt program.
Preemptive and Non-Preemptive Threads
Most Java implementations provide preemptive threads. However, the current Sun Solaris implementation provides non-preemptive
threads. The difference between these two models can lead to very different performance and programming requirements.
Threads of Control
Each concurrently operating task in the Java virtual machine is a thread. Threads exist in various states, the important ones being
RUNNING, RUNNABLE, or BLOCKED.
A RUNNING thread is a currently executing thread. ●
A RUNNABLE thread can be run once the current thread has relinquished control of the CPU. There can be many threads in the
RUNNABLE state, but only one can be in the RUNNING state. Running a thread means changing the state of a thread from
RUNNABLE to RUNNING, and causing the thread to have control of the Java Virtual Machine (VM). ●
A BLOCKED thread is a thread that is waiting on the availability of some event or resource. ●
Note
The Java VM schedules threads of the same priority to run in a round-robin mode.
Preemptive Threading
The main performance difference between the two threading models arises in telling a running thread to relinquish control of the Java VM.
In a preemptive threading environment, the usual procedure is to set a hardware timer that goes off periodically; when the timer goes off,
the current thread is moved from the RUNNING to the RUNNABLE state, and another thread is chosen to run.
Non-Preemptive Threading
In a non-preemptive threading environment, a thread must volunteer to give up control of the CPU and move to the RUNNABLE state.
Many of the methods in the Java language classes contain code that volunteers to give up control, and are typically associated with actions
that might take a long time. For instance, reading from the network will generally cause a thread to wait for a packet to arrive. A thread
that is waiting on the availability of some event or resource is in the BLOCKED state. When the event occurs or the resource becomes
available, the thread becomes RUNNABLE.
Using Jolt with Non-Preemptive Threading
If your Jolt-based Java program is running on a non-preemptive threading Virtual Machine (e.g., Sun Solaris), then the program must
either:
Occasionally call a method that blocks the thread ●
Explicitly give up control of the CPU using the Thread.yield() method ●