Multi-threaded translation
An engine process has a command thread (the “scheduler”), a translation thread, and protocol threads.
The translation thread can have multiple operating system sub-threads that run outside the engine’s scheduler. It can perform all transformations within a process with a single translation thread per process, or with a multi-threaded translation per process. This permits protocol threads to run when translations are being processed. If the computer has more than one processor, then threads use the full power of the machine. The sub-threads, when working on a translation, are under the control of the operating system. These can be assigned to any available CPU or suspended as required when more important tasks must be handled.
Multi-threaded translation configuration
In the Process Configuration dialog box, select and click to set up multi-threaded translations. This opens the Multi-threaded Translation dialog box.
When this option is not selected, the behavior is only one translation thread per process. In this case, the number of translation sub-threads is "0."
This tables shows the available options in configuring a multi-threaded translation:
Option | Description |
---|---|
Number of Translation Sub-threads | This specifies the number of translation sub-threads to be used. Select from 1 to 16; the default value is 1. |
This specifies how messages from a source protocol thread are ordered. This option is unavailable when the number of translation sub-threads is equal to 1; otherwise, it is enabled.
Whichever type is selected, its respective help information is shown in the text area. |
|
(default) | You can restrict the use of Tcl interpreters by clicking one of the
Tcl Interpreters option buttons. These options are used to specify how Tcl interpreters are selected. This is because if in your Tcl procedures globals are created and used, the same interpreter must be used for every translation. In addition to the Tcl procedures that are associated with an xlate, there are Tcl fragments that can be used in the actual translations. These are used to set or modify the values placed in the output of the translation. When fragments are run by Tcl, the same interpreter is used as other Tcl user calls in the xlate processing. All xlates use the same Tcl interpreter independent of the source or type of the message. Thus at any given time, there can be only one Tcl procedure running. Tcl procedures are called in the start and shutdown modes. This is the safest mode if you are not absolutely sure about the Tcl that is used in translation. This gives the worst performance. Because
|
No Tcl run that is in the xlates uses any global. The interpreter that
is used for the translation of a message can be any that are
available independent of the message source. The start and shutdown mode calls to the Tcl procedures are not called in this mode. In this case, an interpreter that is specific to the sub-thread doing the translation is used for the procedure calls. The interpreter that is used can vary from message to message. Java UPoCs can only use the unrestricted Tcl mode if the number of sub-threads in xlate is not zero. |
|
Each source of a data message gets an interpreter for xlate
processing. This is used for all Tcl user-defined calls related to the message. In the case of a reply message, the source is considered to be the original source thread to which the reply is connected. The start and shutdown mode calls are made for each procedure before it is used in the translation. This interpreter is used in case you set globals for the outbound message that is required to process the reply. Note that this setting is applied only if the number of sub-threads is not zero. This ensures that zero sub-thread processing is exactly the same as the previous version of the xlate thread. |
|
A Tcl list of message sources that are to be unrestricted as to which
interpreter is used. Message sources not in the list are restricted
to a single interpreter independent of the message source. The text
field and Using this value can yield the best performance if the use of Tcl globals varies by message source. When this option is selected, clicking Threads dialog box. This lists all threads that are under the selected process. On this dialog box, you select the threads as message sources that are not to be restricted to which interpreter is used if required. Selected threads display in the text field. opens a |
are available only when this option is
selected.