Может быть, кто-то из линуксоидов просветит на этот счёт.[b][color=#008000]IvanLis[/color][/b] писал(а):Если Вы лодку погрузите на машину, это не значит, что машина станет водным судном.
Кстати, наткнулся тут на механизм работы Wait (ms). Инфа размещена здесь - LabVIEW Timing Mechanism, я скопирую её сюда для сохранения целостности темы.
То есть, в очень упрощённом виде инструмент Wait (ms) аналогичен такому коду: На самом деле в LV множество потоков, и если упрощать до этого уровня, то поток приложения активирует Occurrence через OccurAtTime, а поток LV Execution System периодически проверяет список Occurrences через ChkOccurrences. А вот как сами Occurrences работают - это уже другой вопрос.Date: Tue, 15 Jun 1999 06:47:00 -0500
From: gam@natinst.com (Greg McKaskle)
Subject: Re: [W] Timing Quality?
Organization: National Instruments
The two wait functions, plus the timeouts on occurrences are all based on the same mechanism. Arithmetic is done to determine how long the node needs to suspend execution, and it sets up an occurrence. The occurrence manager keeps all of the timeout items sorted on a list, and it has a thread that calls Sleep with the smallest timeout in millisecs.
On nonwindows OSes with threads it may call nanosleep or other various functions for the OS to wake up the thread in N ms. For OSes without threads, this list is polled from time to time from the execution system to notice when occurrences have timed out and to schedule them.
Occurrences with a wait of 0 ms are never put on this list, and in fact wait nodes with 0 ms never even generate an occurrence, they are a special lower overhead case depending on the threading model.
Once the occurrences have been dispatched, the nodes have being scheduled on their various execution system queues. The execution system is either busy executing other code, or it has a thread waiting to execute (waiting on an event). If there is a waiting thread, the thread will be signaled in the process of queuing the node. If there are no threads available for that execution system, it will wait until the diagram code yields and schedules the next node in the queue.
If there are lots of wait functions going off in parallel, which includes all running VIs within one LV runtime, then it is up to LV as to what order they are queued in, and it is then up to the OS as to which order the threads that were signaled, get scheduled in and how the scheduling happens between the threads.
In summary, for a single wait function, the operations are:
- ● Calculate the wakeup delay, put a high priority thread asleep for delay ms.
- ● The thread that executed the wait function either starts executing parallel code that was already on the execution queue, or it calls WaitForSingleEvent.
- ● When the high priority thread wakes up from sleep, it signals the waiting thread if necessary and transfers the node information to the execution queue.
- ● The execution system thread can then resume the diagram code based on normal scheduling rules, and the high prioroty occurrence thread either goes to sleep for the next delay amount or calls WaitOnSingleEvent for another occurrence to be put on the list.
И, в принципе, понятно, почему задержка именно так сделана, а не скажем через стандартный виндовый Sleep - на Линуксе и Маке свои собственные реализации задержек, а должен поддерживать множество платформ.
Не менее интересная статья на том же сайте - Studying LabVIEW Using QueryPerformanceCounter, показывающая, как механизм Windows влияет на работу приложения в . Хотя эксперименты проводились 17 с лишним лет назад (!) на LV 5.0, полученные данные до сих пор актуальны на современных версиях Windows (что мы и получили в результате). В конечном счёте всё сводится к тому, что для получения чёткого детерминизма в работе программы её нужно запускать на RT OS, а Винда никак не подходит на эту роль.