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





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
[Win32] А почему GetLocalTime должна работать медленнее? 16.10.08 07:58  Число просмотров: 2534
Автор: 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-2021 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach