|
<< 点击显示目录 >> 主页 exOS使用助手 > exOS Automation Help > Development > Programming > exOS Communication API reference (exos_api.h) > exos_datamodel_process() |
循环主函数--轮询数据模型以获取传入信息
EXOS_ERROR_CODE exos_datamodel_process(exos_datamodel_handle_t *datamodel)；
每个数据模型都能接收来自 数据集消息路由器的值变化或任何其他信息 。在 Linux 系统中，exos_datamodel_process() 会以阻塞方式轮询传入的消息，它与 数据集消息路由器的循环同步 ，在共享内存连接中，数据集消息路由器与配置的 AR 任务类同步。如果有很多传入消息，例如大量数据集更新，exos_datamodel_process() 就会读出所有待处理消息，并在调用它的上下文中调用已注册的回调，直到没有更多消息为止。换句话说，如果数据集收到了新值，数据集事件回调会同步调用 exos_datamodel_process()。
如果需要非阻塞（非同步）行为， exos_datamodel_set_process_mode() 函数可以在应用程序中随时更改 exos_datamodel_process() 的执行策略。
在 AR 中，exos_datamodel_process() 是非阻塞的，但应在与 数据集消息路由器相同的任务类中运行 。
•datamodel：数据模型句柄，以指针形式给出
调用 exos_datamodel_process() 的频率将决定应用程序对来自服务器的变化的反应时间，建议在紧循环中运行，使应用程序与 数据集消息路由器同步 。 如果反应时间较慢，也不会丢失任何数据，因为应用程序和 数据集消息路由器之间的消息 是在内部排队的，如果在下一次 exos_datamodel_process() 时有一系列变化，这些变化将在一次扫描中全部触发。
不过 ，重要的是 要在配置的心跳超时时间内调用 exos_datamodel_process()，否则 数据集消息路由器 会认为数据模型的连接已丢失，并将应用程序（在 Linux 和 AR 上）带入 EXOS_STATE_DISCONNECTED。当然，日志中会显示一个错误（请参阅 ExData Logger）。
在 Linux 上，exos_datamodel_process() 会等待 来自 数据集消息路由器（Dataset Message Router）的每一次同步事件 ，当前的 NETTIME 也会随之更新。该 NETTIME 值用于从 exos_datamodel_get_nettime() 函数中获取外推（当前） NETTIME 值 。
Cyclic main function - poll datamodel for incoming messages
EXOS_ERROR_CODE exos_datamodel_process(exos_datamodel_handle_t *datamodel);
Each datamodel can receive value changes or any other information coming from the Dataset Message Router. The exos_datamodel_process() polls incoming messages in a blocking manner in Linux, where it synchronizes with the loop of the Dataset Message Router, which - in a shared memory connection - is synchronized with a configured AR task class. If there are many incoming messages, for example a lot of dataset updates, the exos_datamodel_process() will read out all pending messages and call the registered callbacks from the context it is called, until there are no more messages. In other words, if a dataset has received a new value, the datasetEvent callback is called synchonously to exos_datamodel_process().
Should a non-blocking (non-synchronous) behaviour be desired, the exos_datamodel_set_process_mode() function can change the execution policy for exos_datamodel_process() at any time in the application.
In AR the exos_datamodel_process() is non-blocking, but should run in the same task-class as the Dataset Message Router.
•datamodel: datamodel handle, given as a pointer
How often you call the exos_datamodel_process() will determine the reaction time of your application in case of changes coming from the server, and it is recommended to run it in a tight loop giving the application a synchronous behaviour to the Dataset Message Router. You will not loose any data using a slow reaction time, as the messages between the application and the Dataset Message Router are queued internally, and if you have a set of changes coming in on the next exos_datamodel_process(), these will be triggered all in one sweep.
It is, however, important to call the exos_datamodel_process() within the configured heartbeat timeout, otherwise the Dataset Message Router will consider the connection of the datamodel to be lost, and bring the application (on Linux and AR) to an EXOS_STATE_DISCONNECTED. Here, of course, an error will be visible in the log (see ExData Logger)
At every synchronization event from the Dataset Message Router, which the exos_datamodel_process() waits for on Linux, the current NETTIME is also updated. This NETTIME value is used to get an extrapolated (current) NETTIME value from the exos_datamodel_get_nettime() function.