[Win32] А почему GetLocalTime должна работать медленнее?16.10.08 07:58 Число просмотров: 3050 Автор: HandleX <Александр М.> Статус: The Elderman Отредактировано 16.10.08 07:58 Количество правок: 1
Даже удивительно, что так долго они работают, поскольку вроде как структуры данных этих переменных обновляются ядром по прерываниям железа, но лежат они в разделяемой памяти, которая read-only для пользовательских процессов, и основное, на что тратится время при чтении -- на примитивы синхронизации.
и посмотреть загрузку kernel CPU/user CPU. Как говориться не уверен - не обгоняи и не задавай глупых вопросов ;)
[Win32] А почему GetLocalTime должна работать медленнее?16.10.08 07:58 Автор: HandleX <Александр М.> Статус: The Elderman Отредактировано 16.10.08 07:58 Количество правок: 1
Даже удивительно, что так долго они работают, поскольку вроде как структуры данных этих переменных обновляются ядром по прерываниям железа, но лежат они в разделяемой памяти, которая read-only для пользовательских процессов, и основное, на что тратится время при чтении -- на примитивы синхронизации.
Да, ты прав. Я проверил. Если читать SystemTime,...18.10.08 06:16 Автор: void <Grebnev Valery> Статус: Elderman
> Даже удивительно, что так долго они работают, поскольку > вроде как структуры данных этих переменных обновляются > ядром по прерываниям железа, но лежат они в разделяемой > памяти, которая read-only для пользовательских процессов, и > основное, на что тратится время при чтении -- на примитивы > синхронизации.
Да, ты прав. Я проверил. Если читать SystemTime, InterruptTime KUSER_SHARED_DATA по адресу 0x7FFE0000 (или 0xffdf0000 kernel mode), аналогично тому как это делают KiQueryInterruptTime, KiQuerySystemTime, например, при помощи пары вызовов InitTime(void)/NT_GetKernelTime(void) из
документа http://research.microsoft.com/invisible/src/base/md/i386/sim/_glue.c.htm,
то получим приблизительно тоже время, что и ::GetSystemTime().
Так что похоже, что никакой синхронизации (и примитивов синхронизации) там нет - ::GetSystemTime() похоже тупо читает KUSER_SHARED_DATA.
Ну мож и нет примитивов, поскольку эти структуры обновляются...18.10.08 08:02 Автор: HandleX <Александр М.> Статус: The Elderman
Ну мож и нет примитивов, поскольку эти структуры обновляются ядром в прерываниях на высоких IRQ level'ах, + наверное LOCK-префиксы инструкций записи, то их никто не сможет читать во время записи, что и требуется.
Может читать и читает. Там просто есть "примитивное...18.10.08 21:55 Автор: void <Grebnev Valery> Статус: Elderman
> Ну мож и нет примитивов, поскольку эти структуры > обновляются ядром в прерываниях на высоких IRQ level'ах, + > наверное LOCK-префиксы инструкций записи, то их никто не > сможет читать во время записи, что и требуется.
Может читать и читает. Там просто есть "примитивное использоване примитивов", поскольку ISR не может использовать никаких "lock", но должен обновить KSYSTEM_TIME как можно быстрее:
1) ISR (clock interrupt service routine) обновляет данные в строгом порядке:
вначале High2Time, затем LowPart, и в последнюю очередь High1Time.
2) Пользовательское приложение читает данные в обратном порядке:
High1Time, затем LowPart, и в последнюю очередь High2Time.
Синхронизация в том, что если High1Time != High2Time, то чтение повторяется снова (loop)
Например,
while (true) {
myTime.High1Part = USER_SHARED_DATA->SystemTime.High1Time;
myTime.LowPart = USER_SHARED_DATA->SystemTime.LowPart;
if (myTime.High1Part == USER_SHARED_DATA->SystemTime.High2Time)
{
break;
}
else
{
// _asm { pause } не уверен
}
}
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
