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





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
QueryPerformanceCounter(); QueryPerformanceFrequency 15.06.01 21:54  Число просмотров: 1417
Автор: + <Mikhail> Статус: Elderman
<"чистая" ссылка>
esli men`she chem 1ms ispolzuiii eti foo

P.S.
Processor dependent
<programming>
[Win32] Как мне грамотно организовать полинг в WinApplication? 13.06.01 14:07  
Автор: Xan Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Нужно воткнуть бесконечный цикл, в котором шел бы непрерывный опрос, ну, скажем, значения некоторой переменной. Как мне это сделать корректно?
Проблема даже не в том, что если это делать в лоб, я не смогу обрабатывать
остальные сообщения из своей программы, а в том, что когда в программе
такой цикл запускается, все остальные приложения зависают до тех пор, пока задача не будет убита.
[Win32] все проще 13.06.01 22:14  
Автор: kabanchik Статус: Незарегистрированный пользователь
<"чистая" ссылка>
"прикрепи" к своему объекту Event, запусти поток(и), как ребята уже сказали, поставь его (их) в состояние ожидания.
когда данные объекта изменяться ставит Event в состояние signaled.
поток(и) заитересованные в нем получат уведомление, возобновит(ят) работу и просмотрят данные, а до этого смысла нет в холостую крутиться и захватывать процессорное время.
sleep(timeout) в цикле и не парить голову :) 13.06.01 19:26  
Автор: XR <eXtremal Research> Статус: The Elderman
<"чистая" ссылка>
Если бы не времена опроса меньше 1mS проблем бы не было :( 14.06.01 13:42  
Автор: Xan Статус: Незарегистрированный пользователь
<"чистая" ссылка>
QueryPerformanceCounter(); QueryPerformanceFrequency 15.06.01 21:54  
Автор: + <Mikhail> Статус: Elderman
<"чистая" ссылка>
esli men`she chem 1ms ispolzuiii eti foo

P.S.
Processor dependent
такого времени опроса (гарантированного) тебе не даст сделать шедулер Win - меняй OS на чего нибудь RT 14.06.01 13:57  
Автор: XR <eXtremal Research> Статус: The Elderman
<"чистая" ссылка>
... или если плевать на гарантии ставь sleep(0)
Можно и не менять 14.06.01 13:06  
Автор: prop Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Гарантированное время опроса в Win32 можно получить только на уровне драйверов устройств (тех самых, которые никто не любит писать), для этого они и созданы.
Если надо приблизится к гарантированному времени - тогда можно потоку дать приоритет real-time (только надо разобраться с абсолютными и относительными приоритетами - RTFM). В принципе, должно работать быстро, но не гарантировано - твой процесс, например, могут выпихнуть в своп, и тогда дополнительное время уйдет на подгрузку. Я всего этого не пробовал, поэтому больше предполагать не буду. Если чего получится - опубликуй.
А чтоб протестить можешь просто своему процессу поставить real-time в таск манагере (НТ) - если все не умрет, значит написал правильно.
[Win32] Можно и не менять 15.06.01 09:54  
Автор: cb <cb> Статус: Member
<"чистая" ссылка>
> Гарантированное время опроса в Win32 можно получить только
> на уровне драйверов устройств (тех самых, которые никто не
> любит писать), для этого они и созданы.

ну я бы не сказал что они сделаны "именно для ЭТОГО"...
даже в драйвере (речь про WinNT/Win2k) тебе никто ничего не гарантирует.
существуюс спец. навески на NT которые максимально приближают эту ось
к real-time системам, но все эти вещи по сути представляют из себя ось в оси и никак не завязаны даже на ядро NT не говоря уже о UserMode.
Вот тут Q94265 посмотри. Я не проверял этих самых good real-time capabilities, но видел real-time системы с урезанным (но без всяких навесок) НТ. 15.06.01 18:06  
Автор: prop Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> > Гарантированное время опроса в Win32 можно получить
> только
> > на уровне драйверов устройств (тех самых, которые
> никто не
> > любит писать), для этого они и созданы.
>
> ну я бы не сказал что они сделаны "именно для ЭТОГО"...
> даже в драйвере (речь про WinNT/Win2k) тебе никто ничего не
> гарантирует.
> существуюс спец. навески на NT которые максимально
> приближают эту ось
> к real-time системам, но все эти вещи по сути представляют
> из себя ось в оси и никак не завязаны даже на ядро NT не
> говоря уже о UserMode.
Можно и не менять 14.06.01 15:52  
Автор: XR <eXtremal Research> Статус: The Elderman
<"чистая" ссылка>
> Если надо приблизится к гарантированному времени - тогда
> можно потоку дать приоритет real-time (только надо
> разобраться с абсолютными и относительными приоритетами -
> RTFM). В принципе, должно работать быстро, но не
> гарантировано - твой процесс, например, могут выпихнуть в
> своп, и тогда дополнительное время уйдет на подгрузку. Я
> всего этого не пробовал, поэтому больше предполагать не
> буду. Если чего получится - опубликуй.

Есть как минимум 2 НО:

1) REALTIME_PRIORITY_CLASS доступен тилько группе администраторов
2) Есть очень ненулевая вероятность залочить систему насмерть RT процессом
потому как большая часть системы работает с более низким классом приоритета
(не спасет даже комбинация из 3-х пальцев :))


> А чтоб протестить можешь просто своему процессу поставить
> real-time в таск манагере (НТ) - если все не умрет, значит
> написал правильно.

Это обычно называется "отладка методом русской рулетки" :)))
Нее, это "отладка методом научного тыка" :)) 14.06.01 16:45  
Автор: prop Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> > Если надо приблизится к гарантированному времени -
> тогда
> > можно потоку дать приоритет real-time (только надо
> > разобраться с абсолютными и относительными
> приоритетами -
> > RTFM). В принципе, должно работать быстро, но не
> > гарантировано - твой процесс, например, могут
> выпихнуть в
> > своп, и тогда дополнительное время уйдет на подгрузку.
> Я
> > всего этого не пробовал, поэтому больше предполагать
> не
> > буду. Если чего получится - опубликуй.
>
> Есть как минимум 2 НО:
>
> 1) REALTIME_PRIORITY_CLASS доступен тилько группе
> администраторов
> 2) Есть очень ненулевая вероятность залочить систему
> насмерть RT процессом
> потому как большая часть системы работает с более низким
> классом приоритета
> (не спасет даже комбинация из 3-х пальцев :))
>
>
> > А чтоб протестить можешь просто своему процессу
> поставить
> > real-time в таск манагере (НТ) - если все не умрет,
> значит
> > написал правильно.
>
> Это обычно называется "отладка методом русской рулетки"
> :)))
Так вот, тыкал я тыкал... =) 15.06.01 10:08  
Автор: Xan Статус: Незарегистрированный пользователь
<"чистая" ссылка>
И вроде заработало так:
BOOL fRetVal = TRUE;
while(!fTimeout)
{
memset(&lpMsg,0,sizeof lpMsg); // убираем предыдущее
PeekMessage(&lpMsg, 0, 0, 0, PM_REMOVE);
if (lpMsg.message == WM_QUIT)
{ fRetVal = FALSE;
break;
}
TranslateMessage(&lpMsg);
DispatchMessage(&lpMsg);

Сори, мессага здесь. 15.06.01 10:21  
Автор: Xan Статус: Незарегистрированный пользователь
<"чистая" ссылка>
BOOL fRetVal = TRUE;
while(!fTimeout) // Тут глобальный флаг
{
memset(&lpMsg,0,sizeof lpMsg); // убираем предыдущее
PeekMessage(&lpMsg, 0, 0, 0, PM_REMOVE);
if (lpMsg.message == WM_QUIT)
fRetVal = FALSE, break;

TranslateMessage(&lpMsg);
DispatchMessage(&lpMsg);
if(MYREGISTER) MYHANDLER(); // Во, наш полинг!
}
...
return fRetVal;

Так все же я не понял. Объясните мне тупому. Если я не собираюсь генерировать сообщения каждую милисекунду, а всего лишь хочу крутить свой цикл так быстро, как только получиться, неужели ось не даст мне это сделать быстрее, чем тысячу раз в секунду. И еще про шедуллер я не совсем понял, причем сдесь он.
Спасибо, кто прочел.
Сори, мессага здесь. 15.06.01 16:59  
Автор: prop Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Так все же я не понял. Объясните мне тупому. Если я не
> собираюсь генерировать сообщения каждую милисекунду, а
> всего лишь хочу крутить свой цикл так быстро, как только
> получиться, неужели ось не даст мне это сделать быстрее,
> чем тысячу раз в секунду.
Даст. Но если будет более приоритетный поток (все потоки ядра более приоритетны чем пользовательские), и он будет что-нибудь делать, то ты своего кванта не получишь, пока он не освободится.

И еще про шедуллер я не совсем
> понял, причем сдесь он.
Смотря какой. Task Scheduer сервис занимается совсем другим и здесь нипричем. Но где-то в ядре есть нечто очеь приоритетное, что управляет переключением потоков - если назвать его шедулером, то он причем. Как называет его микрософт я не знаю.

> Спасибо, кто прочел.
Всегда пожста.

Совет дня:
Если пишешь коммерческую прогу, которая должна гарантированно работать на любой машине, надо изучать DDK. Гарании по быстродействию есть только в нулевом кольце.
Если надо решить локальную задачу по управлению любимой кофеваркой или электрочайником то разберись с потоками и приоритетами. А потом поубивай все ненужные сервисы и задачи на машине - включая explorer. Если есть два процессора, поставь свою задачу на один, а все остальное - на другой. (Affinity Mask). Правда с ядром такие штуки не пройдут.
Чем быстрее машина, тем быстрее крутится твой цикл. Если машина больше ни хрена не делает - значит и задержек нет. (если возникла задержка - значит плохо предохранялись :)).
Сори, мессага здесь. 15.06.01 12:16  
Автор: XR <eXtremal Research> Статус: The Elderman
<"чистая" ссылка>
> BOOL fRetVal = TRUE;
> while(!fTimeout) // Тут глобальный флаг
> {
> memset(&lpMsg,0,sizeof lpMsg); // убираем предыдущее
> PeekMessage(&lpMsg, 0, 0, 0, PM_REMOVE);
> if (lpMsg.message == WM_QUIT)
> fRetVal = FALSE, break;
>
> TranslateMessage(&lpMsg);
> DispatchMessage(&lpMsg);
> if(MYREGISTER) MYHANDLER(); // Во, наш полинг!
> }
> ...
> return fRetVal;
>
> Так все же я не понял. Объясните мне тупому. Если я не
> собираюсь генерировать сообщения каждую милисекунду, а
> всего лишь хочу крутить свой цикл так быстро, как только
> получиться, неужели ось не даст мне это сделать быстрее,
> чем тысячу раз в секунду.

при большой загрузке не даст - отчего и говорить про гарантии не приходится ...
...тем более с вышеприведенным кодом, завязанным на очередь сообщений...
И еще про шедуллер я не совсем
> понял, причем сдесь он.

он здесь при том что стратегия планирования в NT не ориентирована на ГАРАНТИРОВАННОЕ время отклика ...

BTW: вообще то планировщик NT вещь довольно темная :)


PS: кстати никто не напомнит величину стандартного таймслайса для NT ?

> Спасибо, кто прочел.
[Win32] Сори, мессага здесь. 15.06.01 17:00  
Автор: cb <cb> Статус: Member
<"чистая" ссылка>
> PS: кстати никто не напомнит величину стандартного
> таймслайса для NT ?

это про планировщик? если да то если мне не изменяет память - 10 миллисекунд
[Win32] 25 milliseconds 15.06.01 22:33  
Автор: + <Mikhail> Статус: Elderman
<"чистая" ссылка>

P.S.
An important exception is that threads at the highest priority level (level 0, THREAD_PRIORITY_TIME_CRITICAL) do not share the time slice with other threads at the highest priority level. These threads continue executing until they have finished.
[Win32] Как мне грамотно организовать полинг в WinApplication? 13.06.01 17:56  
Автор: prop Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Если WinApplication=Win32Application, то грамотно такие вещи делаются в отдельном потоке. Создаешь поток, ставишь ему приоритет - и вперед.
Если ты дельфируешь, то там есть готовый объект - TThread, очень удобный.
Если лень связываться с потоками сделай по таймеру - самое часте раз в миллисекунду.
В обоих случаях ничего не повисает.
Если первые два способа не подходят, и ты опять же дельфируешь, то в своем бесконечном цикле каждый раз после проверки вызывай Application.ProcessMessages - ничего не повиснет, все формы будут перерисовываться, можешь даже нажатия клавиш получать.
OK. А если под 'чистым' API, то как мне Application.ProcessMessages имитировать 13.06.01 18:41  
Автор: Xan Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Если WinApplication=Win32Application, то грамотно такие
> вещи делаются в отдельном потоке. Создаешь поток, ставишь
> ему приоритет - и вперед.
> Если ты дельфируешь, то там есть готовый объект - TThread,
> очень удобный.
> Если лень связываться с потоками сделай по таймеру - самое
> часте раз в миллисекунду.
> В обоих случаях ничего не повисает.
> Если первые два способа не подходят, и ты опять же
> дельфируешь, то в своем бесконечном цикле каждый раз после
> проверки вызывай Application.ProcessMessages - ничего не
> повиснет, все формы будут перерисовываться, можешь даже
> нажатия клавиш получать.

Примерно так 14.06.01 12:43  
Автор: prop Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Это из исходников Дельфей. Просто вызывается PeekMessage.
Хинт - то что начинается на F - это приватные переменные класса TApplication - можно похерить.

procedure TApplication.ProcessMessages;
var
Msg: TMsg;
begin
while ProcessMessage(Msg) do;
end;

function TApplication.ProcessMessage(var Msg: TMsg): Boolean;
var
Handled: Boolean;
begin
Result := False;
if PeekMessage(Msg, 0, 0, 0, PM_REMOVE) then
begin
Result := True;
if Msg.Message <> WM_QUIT then
begin
Handled := False;
if Assigned(FOnMessage) then FOnMessage(Msg, Handled);
if not IsHintMsg(Msg) and not Handled and not IsMDIMsg(Msg) and
not IsKeyMsg(Msg) and not IsDlgMsg(Msg) then
begin
TranslateMessage(Msg);
DispatchMessage(Msg);
end;
end
else
FTerminate := True;
end;
end;
1  |  2 >>  »  




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


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