Текущий архив: 2006.03.26;
Скачать: CL | DM;
Вниз
Можо ли ждать события, но не усыплять поток? Найти похожие ветки
← →
Kolan © (2006-02-22 15:11) [0]Здравствуйте,
Если использовать функциюWaitForSingleObject, то поток уснет и будет ждать пока не случится событие или таймаут...
Есть ли возможность сделать так, чтобы во время ожидания поток не засыпал а делал еще что-то?
← →
Fay © (2006-02-22 15:14) [1]2 Kolan © (22.02.06 15:11)
Так, что-ли ?
while WaitForSingleObject(..., 0) = WAIT_TIMEOUT do
<что-то ещё>
← →
clickmaker © (2006-02-22 15:15) [2]низзя
нужно что-то делать параллельно - запускай еще один поток
либо в цикле периодически проверять состояние этого самого Object
← →
Kolan © (2006-02-22 15:43) [3]clickmaker © (22.02.06 15:15) [2]
Так я и знал.
Тогда еще вопрос...
Есть большая и длинная функция(она такая и должна быть), которая должна работать с com портом, нарисовать графики, много еще чего...
Для управления всеми функциями есть менеджеры... А менеджерами управляет главный..
Все это находится в главном потоке...
Внутри функция должна выполнить запросы к Com порту и если недождалась ответов, завершится... Для этого используюWaitForSingleObject
Так вот проблемма в то, что когда гл. поток засыпает он неможет получить и обработать сообщение, о том, что приняты данные из порта..
Он получает его, только когдаWaitForSingleObjectпрекращается по тайм ауту...
Засунуть ее в другой поток сложно.. тк тогда этому потоку нужно знать о существовании всех используемых менеджеров.. И менеджеры не предназначены для использования несколькими потоками...
Чтобы придумать..
Может сделать поток как-бы самым первым в иерархии, пусть он управляет главным менеджером..
Вообщем что делать? :)
← →
ANB © (2006-02-22 15:52) [4]Выставлять разумный таймаут. И все делать в цикле.
← →
Kolan © (2006-02-22 16:09) [5]Яделаю так.
А разумный таймаут не помогает.... Или проскакивает и говорит что тайм аут или подвисает...Attempts := 1;
while Attempts <= MaxErrorCount do
begin
if WaitForSingleObject(FImpedanceWaitEvent, WaitImpeadnceEventTimeOut)
= WAIT_OBJECT_0 then
begin
if FImpedanceData.FIsProgress then
begin
Attempts := 0;
PostMessage(FFormHandle, SX_SELFGRADUATINGEVENT,
Integer(sgeProgress), FImpedanceData.FProgress);
MyProsessMessages;
end
else
begin
// Èìïåäàíñ èçìåðåí.
MyProsessMessages;
FCurrentGraphManagerAndDataHolder.GraphManager.ChangeGraphType(gtLineSerie);
FCurrentGraphManagerAndDataHolder.GraphManager.Graphs[0].AddDoublePointArray(
FImpedanceData.FRealPart);
FCurrentGraphManagerAndDataHolder.GraphManager.Graphs[1].AddDoublePointArray(
FImpedanceData.FImaginativePart);
IsOverFlow := False;
Break;
end;
end
else
begin
PostMessage(FFormHandle, SX_SELFGRADUATINGEVENT,
Integer(sgeErrorOverFlow), Attempts);
MyProsessMessages;
IsOverFlow := True;
//
ProtocolManager.WriteString("Íåäîæäàë 41;ÿ îòâåòà.");
//
end;
Attempts := Attempts + 1;
end;
← →
Kolan © (2006-02-22 16:16) [6]Те получается так:
Уже пакет готов а он все еще ждет тк SetEvent выполняется в этом же потоке, а он спит. Это при большом таймауте...
А при маленьком проскакивает не успев дождаться...
← →
Сергей М. © (2006-02-22 16:29) [7]
> Есть ли возможность сделать так, чтобы во время ожидания
> поток не засыпал а делал еще что-то?
Нет такой возможности.
← →
evvcom © (2006-02-22 16:48) [8]1. Главный поток оставь для интерфейса.
2. Кто такие "менеджеры" и "главный"? Для опроса/получения данных достаточно 1 менеджера и настраиваемое количество рабочих потоков. Менеджера можно реализовать в том же главном потоке, если только он не будет перегружен работой. Если будет, то скорее всего у тебя где-то логическая ошибка. А можно менеджера в доп.потоке реализовать. Как хочешь.
← →
Сергей М. © (2006-02-22 17:03) [9]
> Kolan © (22.02.06 15:11)
Кодовый поток, вызвавший одну из WaitFor-ф-ций, "отдался во власть режима ядра" - с этого момента ядро ответственно за "жизнь потока".
Поток "заснул". Ядро при этом ответственно как за его "пробуждение" (если поток что-либо ждет), так и за вызов callback-функций в контексте потока (если поток при этом подразумевает alertable state - "на стрёме")
← →
evvcom © (2006-02-22 17:08) [10]
> alertable state - "на стрёме")
чистА русский перевод :)
← →
Defunct © (2006-02-23 06:16) [11]Kolan © (22.02.06 16:16) [6]
> Уже пакет готов а он все еще ждет тк SetEvent выполняется
> в этом же потоке, а он спит. Это при большом таймауте...
Если все в одном потоке, тогда какой смысл в использовании Events?
можно ведь просто завести булеву переменную... Лучше, конечно, запустить еще один поток.
← →
Evgeny V © (2006-02-23 07:02) [12]Повторюсь
> evvcom © (22.02.06 16:48) [8]
> 1. Главный поток оставь для интерфейса
.
добавлю - для получения информации о каких-либо событиях в главном потоке (имеем ввиду оконное приложение, соответственно поток обработки сообщений главной формы) лучше на мой взгляд использовать естественный для этого потока механизм обработки сообщений. А в потоке работы с портом использовать соответственно PostMessage,SendMessage или Synchronize - на ваше усмотрение. Мне больше нравится для информационных сообщений PostMessage.
← →
Defunct © (2006-02-23 17:34) [13]Evgeny V © (23.02.06 07:02) [12]
нельзя не согласиться с тем, что механизм событий Events в части использования в основном потоке будет хуже механизма сообщений.
Поэтому либо доп поток, либо отказ от Events.
← →
Kolan © (2006-02-23 20:16) [14]Сделал доп поток. Он управляет гл. менеджером...
Events использовал интуитивно. Алгоритм большой и в потоке ему самое место...
Всех благодарю :)
Страницы: 1 вся ветка
Текущий архив: 2006.03.26;
Скачать: CL | DM;
Память: 0.51 MB
Время: 0.03 c
