информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Все любят медПортрет посетителяСтрашный баг в Windows
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
[Win32] А почему GetLocalTime должна работать медленнее? 16.10.08 07:58  Число просмотров: 2861
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 16.10.08 07:58  Количество правок: 1
<"чистая" ссылка>
Даже удивительно, что так долго они работают, поскольку вроде как структуры данных этих переменных обновляются ядром по прерываниям железа, но лежат они в разделяемой памяти, которая read-only для пользовательских процессов, и основное, на что тратится время при чтении -- на примитивы синхронизации.
<programming>
[Win32] QueryPerformanceCounter & GetLocalTime 16.10.08 06:29  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
работают приблизительно с одной и той же скоростью на XP и Vista (~1.5 mcs). Причём на Vista GetLocalTime даже быстрее чем QueryPerformanceCounter.

Почему? GetLocalTime должна бы работать в разы медленнее.
Опровергая себя... 20.10.08 00:57  
Автор: void <Grebnev Valery> Статус: Elderman
<"чистая" ссылка>
> Почему? GetLocalTime должна бы работать в разы медленнее.

Какая глупость! Достаточно было сделать:
	while(true)
	{
		//::QueryPerformanceCounter(&cnt1);
		::GetLocalTime(&tm);
	}

---

и посмотреть загрузку kernel CPU/user CPU. Затем, выполнить

	while(true)
	{
		::QueryPerformanceCounter(&cnt1);
		//::GetLocalTime(&tm);
	}

---

и посмотреть загрузку 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 }  не уверен
        }
    }

---
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach