Using Locks, Threads, and Timeouts Over a LAN

This section gives guidelines to use locks, threads, and timeouts over LAN, including the following subtopics:

• Using Locks and Threads Over a LAN
  • Scenarios to Avoid
  • Recommended Usage
• Using Timeouts with a LAN
  • Client/Server Operation
  • LAN Timeout Functions
  • Default LAN Timeout Values
  • Timeout Algorithm
  • Timeouts in Multi-threaded Applications
  • Timeout Configurations to Avoid
  • Application Terminations and Timeouts

Using Locks and Threads Over a LAN

If two or more threads are accessing the same device or interface using two or more different sessions over LAN, and are using SICL locks to synchronize access, some scenarios may cause timeouts, or may “hang” an application that does not use timeouts.

Scenarios to Avoid

For proper operation, all threads that use their own sessions to access the same device or interface should use the same string to identify the device or interface in their calls to iopen. Therefore, the following scenarios should be avoided.

• Avoid using a hostname to identify the remote host in one call to iopen while using an alias or IP address to identify the same host in another call to iopen.

• Avoid using a device symbolic name, or alias, in one call to iopen (such as “dmm,” where “dmm” equals “gpib,1”) while using the fully specified device name (such as “gpib,1”) in another call.

• Avoid using a remote interface’s logical unit (such as “7”) in one call while using the remote interface’s SICL interface ID (such as “gpib”) in another.

• Avoid using igetintfsess to open an interface session (which internally uses the logical unit to identify the remote interface) while opening the interface with its SICL interface ID for another session.

Recommended Usage

You can avoid each of the above scenarios by always using the same strings to identify the same device or interface in multi-threaded applications. You can also use the igetintfsess function if other sessions use the logical unit instead of the SICL interface ID to specify the interface.

If any thread uses ilock and iunlock to synchronize access to a particular device or interface, all threads accessing that same device or interface using a different session must also use ilock and iunlock. You can also use Win32 synchronization techniques to ensure that a thread does not attempt I/O (iread/iwrite, etc.) to a device already locked via a different session from a different thread within the same process.

If a session has an interface locked, and if a different thread using its own session attempts to lock a device on that interface, the device lock will be held off either until the interface is unlocked by the other thread, or until a timeout occurs on the device lock. This is different from how ilock works on other interfaces (where a lock on a device when the device’s interface is already locked will not hold off the ilock operation, but rather will hold off any subsequent I/O to the device).

Using Timeouts with a LAN

The client/server architecture of the remote I/O software requires use of two timeout values: one for the client and one for the server. The server’s timeout value is the SICL timeout value specified with the itimeout function. The client’s timeout value is the LAN timeout value, which may be specified with the ilantimeout function.

Client/Server Operation

When the client sends an I/O request to the server, the timeout value specified with itimeout or with the SICL default is passed with the request. The server uses that timeout in performing the I/O operation, just as if that timeout value had been used on a local I/O operation.

If the server’s operation is not completed in the specified time, the server sends a reply to the client that indicates that a timeout occurred, and the SICL call made by the application returns I_ERR_TIMEOUT.

When the client sends an I/O request to the server, it starts a timer and waits for the reply from the server. If the server does not reply in the time specified, the client stops waiting for the reply from the server and returns I_ERR_TIMEOUT to the application.

LAN Timeout Functions

The ilantimeout and ilangettimeout functions can be used to set or query the current LAN timeout value. They work much like the itimeout and igettimeout functions. The use of these functions is optional, however, since the software will calculate the LAN timeout based on the SICL timeout in use and the configuration values set via Connection Expert.

Once the application calls ilantimeout, the automatic LAN timeout adjustment is turned off.

A timeout value of 1 used with the ilantimeout function has special significance, causing the LAN client to not wait for a response from the LAN server. However, the timeout value of 1 should be used only in special circumstances and should be used with extreme caution.

Default LAN Timeout Values

Connection Expert specifies two timeout-related configuration values for the LAN software. These values are used by the software to calculate timeout values if the application has not previously called ilantimeout.

LAN Software Timeout Values

LAN maximum timeout

Timeout value passed to the server when an application either uses the SICL default timeout value of Infinity or sets the SICL timeout to infinity (0). Value specifies the number of seconds the server will wait for the operation to complete before returning I_ERR_TIMEOUT. A value of 0 in this field will cause the server to be sent a value of infinity if the client application also uses the SICL default timeout value of infinity or sets the SICL timeout to infinity (0).

Client delta timeout

Value added to the SICL timeout value (server’s timeout value) to determine the LAN timeout value (client’s timeout value). Value specifies the number of seconds.

Timeout Algorithm

Once ilantimeout is called, the software no longer sends the server timeout value to the server and no longer attempts to determine a reasonable client-side timeout. It is assumed that the application itself wants full control of timeouts, both client and server. Also, ilantimeout is per process. That is, all sessions going out over the network are affected when ilantimeout is called.

If the application has not called the ilantimeout function, timeouts are adjusted via the following algorithm:

• The SICL timeout, which is sent to the server for the current call, is adjusted if it is currently infinity (0). In that case it will be set to the Server Timeout value.

• The LAN timeout is adjusted if the SICL timeout plus the Client Delta Timeout is greater than the current LAN timeout. In that case the LAN timeout will be set to the SICL timeout plus the Client Delta Timeout.
• The calculated LAN timeout only increases as necessary to meet the needs of the application, but never decreases. This avoids the overhead of readjusting the LAN timeout every time the application changes the SICL timeout.
• The first iopen call used to set up the server connection uses the Client Delta Timeout specified via Connection Expert for portions of the iopen operation. The timeout value for TCP connection establishment is not affected by the Client Delta Timeout.

To change the timeout values:

1. Exit any applications that use SICL.
2. Run Connection Expert.
   
   Click here to learn how to launching Keysight Connection Expert.

   There are two methods to launch Connection Expert (CE):

   From the Application Finder:

   • Open the Application Finder on your Linux machine.
   • Use any of the following ways to launch Connection Expert:
     • Search for Connection Expert and click to launch the application.
     • Or, search for IO Control and launch it. In the IO Control application, click on the Connection Expert application to it.

   Using a Web Browser:

   • Open your preferred web browser.
   • Enter the URL in the format: https://<IP Address of the machine where IO Libraries Suite is installed>:4211.
     For example: https://10.17.68.235:4211.

4. Click on the TCP/IP interface shown in the explorer view, then click Change Properties... in the properties pane on the right.
5. Change the LAN Maximum Timeout and/or Client Delta Timeout value(s) and click OK to save the changes.
6. Restart your application(s).

Timeouts in Multi-threaded Applications

If you want to manually set the client-side timeout in an application using multiple threads, be aware that ilantimeout may itself time out due to contention for the LAN subsystem, in cases where multiple threads in an application are simultaneously using SICL over LAN.

Thus, if multiple threads are using SICL over LAN at the same time and LAN timeouts are expected by the application, it is recommended that you call ilantimeout only when no other LAN I/O is occurring, such as immediately after session creation (iopen).

If you use the no-wait value and multiple threads are attempting I/O over the LAN, I/O operations using the no-wait option will wait for access to the LAN for two minutes. If another thread is using the LAN interface for longer than two minutes, the no-wait operation will time out.

Timeout Configurations to Avoid

The LAN timeout used by the client should always be greater than the SICL timeout used by the server. This avoids the situation where the client times out while the server continues to attempt the request, potentially holding off subsequent operations from the same client. This also avoids having the server send unwanted replies to the client.

The SICL timeout used by the server should generally be less than infinity. Having the LAN server wait less than forever allows the LAN server to detect network problems or clients that have ceased operation abruptly, and subsequently release resources associated with those clients, such as locks.

Using the smallest possible timeout for your application will maximize the server’s responsiveness to dropped connections, including dropped connections that result from the client application being terminated abnormally. You can set a value less than infinity by setting the LAN Maximum Timeout configuration value in Connection Expert.

Even if your application uses the SICL default of infinity, or if itimeout is used to set the timeout to infinity, by setting the LAN Maximum Timeout value to some reasonable number of seconds, you allow the server to time out, detect network trouble, and release resources.

Application Terminations and Timeouts

If an application is stopped in the middle of a SICL operation performed at the remote I/O server, the server continues to try the operation until the server’s timeout is reached. By default, the remote I/O server associated with an application that is using a timeout of infinity and is stopped may not discover that the client is no longer running for two minutes. If you are using a server other than the Keysight Remote IO Server on Windows or the Keysight E5810 LAN/GPIB gateway, check your server’s documentation for its default behavior.

If your application uses itimeout to set a long timeout value, or if both the LAN client and LAN server are configured to use infinity or a long timeout value, the server may appear “hung” (unresponsive). If this situation occurs, configure the LAN interface (via the Client Delta Timeout value set with Connection Expert) or the Remote IO Server (via its Server Timeout value) to use a shorter timeout value.

If you must use long timeouts, you may reset the server to regain server response. You can reset a remote I/O server by logging into the server system and stopping the Remote IO Server software that is running. This will affect all clients connected to the server. See Troubleshooting SICL Programs for more details. Also, see the documentation on the server you are using for methods to reset the server.