Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | |
Можно и не менять 14.06.01 15:52 Число просмотров: 933
Автор: XR <eXtremal Research> Статус: The Elderman
|
> Если надо приблизится к гарантированному времени - тогда
> можно потоку дать приоритет real-time (только надо
> разобраться с абсолютными и относительными приоритетами -
> RTFM). В принципе, должно работать быстро, но не
> гарантировано - твой процесс, например, могут выпихнуть в
> своп, и тогда дополнительное время уйдет на подгрузку. Я
> всего этого не пробовал, поэтому больше предполагать не
> буду. Если чего получится - опубликуй.
Есть как минимум 2 НО:
1) REALTIME_PRIORITY_CLASS доступен тилько группе администраторов
2) Есть очень ненулевая вероятность залочить систему насмерть RT процессом
потому как большая часть системы работает с более низким классом приоритета
(не спасет даже комбинация из 3-х пальцев :))
> А чтоб протестить можешь просто своему процессу поставить
> real-time в таск манагере (НТ) - если все не умрет, значит
> написал правильно.
Это обычно называется "отладка методом русской рулетки" :)))
|
|
<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;
|
|
|
подробно о проекте
Анализ криптографических сетевых...
