Description
Arbitrated stores can be connected so that they generate an event each time they are are written-to or updated. This event is referred to as an update notification and will unblock all consumers that are currently blocked waiting for an update notification, and all subsequent consumers that have not yet received the notification. If the store is updated more than once while the consumer is not blocked, then it will only receive the last notification. This means is that consumers can keep up to date with 'latest' data. If all the intermediate updates are required then a transient store should be used.
Update notifications do not open the store, they simply notify the consumer that its contents have changed since the last time that it was opened by the consumer. This means that notifications can be asynchronously multiplexed without fear of deadlock (whilst reads cannot). Once notified, the consumer can use a manual connection to open the store for read and retrieve the 'latest' value.
Notes
Internally, update notifications are actually implemented by creating a 'read' access connection with the rule set to CLP_NOTIFY_UPDATED, but will be automatically set if a notification connection is made with the Blueprint editor. An additional Read connection is also required to actually read the data in the store.
Example
GUI which needs to update each time anything changes (to ensure up to date display). The collector starts collecting when the update notification is received, indicating that the data has changed. It then opens the store for read and triggers execution of the call-back which uses the store's record data to update the display.
