![background image](http://html1.mh-extra.com/html/national-instruments/foundation-ni-fbus/foundation-ni-fbus_hardware-and-software-user-manual_709117046.webp)
Chapter 4
NI-FBUS CM Software
NI-FBUS Hardware and Software User Manual
4-8
ni.com
Choose to Write Single-Thread or Multi-Thread Applications
All NI-FBUS functions are synchronous, meaning that the calling
function is blocked until the NI-FBUS call completes. A Fieldbus device
usually takes tens of milliseconds to respond to a block parameter read or
write. It takes longer if any communication errors occur. The NI-FBUS
Communications Manager uses the protocol connections to communicate
with the devices. If a connection is lost, the NI-FBUS Communications
Manager tries to reestablish the connection. When a connection is lost,
an NI-FBUS read or write call may take several seconds to complete.
Single-Thread Applications
If potential delays like the ones discussed in the previous paragraph are
acceptable for your application, you can write your application or the
Fieldbus access part of your application as a single thread. Single-threaded
applications are easier to develop, debug, and test because you do not have
to consider exclusion between threads. If you are writing an application for
testing, monitoring, or configuring a single device, a single-threaded
application might be adequate.
Multi-Thread Applications
If your application monitors or tests several devices at a time,
communication delays might affect the throughput of your application
and therefore be unacceptable. If so, you can develop a multi-threaded
application to improve the performance of your application. There are
several ways to multi-thread your application.
If you are accessing information from function blocks or transducer blocks,
you might want to create a thread for each block. Each block’s thread reads
and writes information for that block. If creating a thread for each block is
excessive, you might consider an architecture in which you have a set of
threads dedicated to Fieldbus I/O. Your application can then interface with
I/O threads through a shared queue in which threads put their I/O requests.
When the I/O completes, the I/O threads can inform the application by
passing a message or some other synchronization scheme.
If your application performs trending or alarm handling, you might
want to have separate threads that perform these functions. You can
make a thread wait for a trend or alarm with the
nifWaitTrend
or
nifWaitAlert
or
nifWaitAlert2
function and then process the trend
or alarm when it arrives. If you are monitoring the live list (the current
list of devices on the bus), you may have a dedicated thread that calls
nifGetDeviceList
because the call will not return until the live list
changes.