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.

Note: Previous NetConfigs can be read by version 6.2 and later. Version 5.8 and later of NetConfig that contains threaded or chained xlate configuration information is not compatible with previous versions.

Multi-threaded translation configuration

In the Process Configuration dialog box, select Multi-threaded Translation and click Configure 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.
Message Ordering

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.

  • Any (default): It is unnecessary for messages taken from the pre-xlate queue to match the order they exit the xlate thread. In general, this gives the best performance in such mode.
  • Ordered. Messages from a source protocol thread must be maintained exactly, so only one message from a source is processed at any given time. Usually, this mode is specified only when the xlate Tcl procedures are maintaining some global variables which require that those messages should be in order.

    This is source-ordered and applies to the sequence of messages from a single source protocol thread. If there are several sources and more than one sub-thread, then overlap processing can happen. This is because translations for more than one source can be active simultaneously.

    Using this value can effect performance when most of the messages are from a single source. This is because the engine operates as if there were no sub-threads.

  • Thread Out: Messages from a source protocol thread can be started at any time but the output of the translation must match the input order. Note that this is source ordering as it only maintains the order of messages from a single source. No order is maintained for messages from several sources.

    This permits several sub-threads to be processing messages from the same source simultaneously. The routing from the translation is in exactly the order they are taken from the preXlate queue.

    Use this setting if you have no Tcl procedures in the xlate that require ordering but the order of messages from the xlate thread must be maintained.

Whichever type is selected, its respective help information is shown in the text area.

All Restricted (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 xlateInVals and xlateOutVals are global variables, All Unrestricted is usually the best performance option to use when doing multi-threaded translates.

All Unrestricted 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.

Per Source 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.

Unrestricted Source List 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 List are available only when this option is selected.

Using this value can yield the best performance if the use of Tcl globals varies by message source.

When this option is selected, clicking List opens a 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.