 | Understanding State Caching |
State caching is a feature of IVI drivers that can improve performance by minimizing the number of I/O calls to an instrument. For instance, if a driver attribute value is set and the driver sends the programmed value to the instrument, subsequent calls to the same attribute need not communicate with the instrument if the value being set is the same as the previous value. Correspondingly, reading a driver attribute need not result in instrument communication if the driver can somehow "remember" the last value that was sent to the instrument. When a client application invokes a driver attribute, the driver caches the value specified in memory so that subsequently the driver can simply retrieve the value from the driver's cache when the attribute is read or avoid making a redundant call to the instrument when the attribute is written. In this way, the instrument I/O traffic is minimized and the overall client application performance can be improved.
Understanding Cache CouplingsWhen a driver caches the value of a attribute, it should ideally return the cached value when the attribute is later read, rather than incurring the performance hit of querying the instrument for the attribute value. This will work so long as nothing takes place within the instrument that would invalidate the value cached in the driver. If, after caching the value of a attribute, the driver performs a different instrument operation that directly or indirectly changes the value of the attribute within the instrument, then the driver's cache and the "real" setting in the instrument are inconsistent. This is one form of what is termed a cache coherency problem.
If setting some driver attribute produces a change in an instrument setting represented by another attribute, the two attributes are said to be coupled. For state caching to work properly, these cache couplings must be programmed into the driver, so that the driver knows when to invalidate specific cached values. For instance, if the driver is caching a Frequency attribute, then setting the Bandwidth attribute may also change the frequency setting within the instrument. This means that the driver must know to invalidate the cached value for the Frequency attribute whenever the Bandwidth is set.
State Caching Features in NimbusNimbus provides two mechanisms for controlling state caching -- automatic state caching and manual state caching. The automatic state caching feature of Nimbus is the simplest to use and will suffice in mostcircumstances. With this technique, Nimbus automatically creates and manages a cache entry for every driver attribute for which state caching has been enabled. The State Caching Editor is used to turn state caching on and off on a attribute-by-attribute basis. The other bit of information that the driver developer must provide via the State Caching Editor is the list of attributes to which the cached attribute is coupled. In other words, the driver developer must specify which driver attributes, when changed, will cause the value of the cached attribute to become invalid. This allows Nimbus to keep its in-memory cache consistent with the settings in the instrument.
In addition to the automatic state caching features of Nimbus exposed by the State Caching Editor, Nimbus also supplies support in the Nimbus Runtime Library for directly manipulating the attribute cache maintained on the driver session. The GetCacheEntry function is used to retrieve a an instance of a CacheEntry class for a particular attribute. Then, functions on the CacheEntry class allow the cached value to be retrieved, updated, invalidated, etc.
When To Enable State CachingState caching is a feature that certainly must be used with care. Cache coherency problems can easily arise if the driver developer is not keenly aware of the details of the instrument behavior and/or does not accurately and thorougly represent instrument couplings in the driver. Thus, in general, it is advisable to consider enabling state caching for those attributes that have the following characteristics:
They require considerable time to execute (and, hence, stand to improve performance the most when cached).
They have a modest and easily expressed set of couplings to other attributes.
Enabling state caching broadly across all attributes in a driver is almost never feasible, as correctly implementing the driver code would involve effectively replicating much of the instrument firmware logic itself. Consequently, Nimbus disables state caching by default for all attributes.
See Also