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





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
::SendMessage() -насколько я знаю чисто APIшный... 14.06.01 00:07  Число просмотров: 811
Автор: Delimiter Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> > > Если WinApplication=Win32Application, то грамотно
> > такие
> > > вещи делаются в отдельном потоке. Создаешь поток,
> > ставишь
> > > ему приоритет - и вперед.
> > > Если ты дельфируешь, то там есть готовый объект -
> > TThread,
> > > очень удобный.
> > > Если лень связываться с потоками сделай по
> таймеру -
> > самое
> > > часте раз в миллисекунду.
> > > В обоих случаях ничего не повисает.
> > > Если первые два способа не подходят, и ты опять
> же
> > > дельфируешь, то в своем бесконечном цикле каждый
> раз
> > после
> > > проверки вызывай Application.ProcessMessages -
> ничего
> > не
> > > повиснет, все формы будут перерисовываться,
> можешь
> > даже
> > > нажатия клавиш получать.
> >
<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-2018 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach