Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Как выводить статус от нескольких потоков? [D5]

Страницы: 1 2 3 >
MegaVolt © (2006-03-02 16:29:00)
Есть несколько потоков выполняющих какую то работу. У каждого потока есть некоторые состояния описывающие то что он делает в конкретный момент времени. Например строка. Как сделать вывод в главной форме этих данных чтобы форма не тормозила из-за того что при синхронизации все опреции происходят через главный поток?

GrayFace (2006-03-06 16:59:00) [1]
Я уж отвык от скорости обсужнения, сравнимой с чатом.

Leonid Troyanovsky © (06.03.06 15:18) [42]
ILI, IDI не обязательны. Конструктор и OnTerminate
выполняются в первичном потоке.
Да, о них я не подумал. OnTerminate будет хорошо, проще. Единственное но - если может выполниться раньше, чем прийдет сообщение сообщение об обновлении статуса. Хотя, тоже не проблема - вызвать вначале Application.ProcessMessages и все.

В общем, PostMessage будет побыстрее и особых проблем, я думаю, не вызовет - PocessMessages в OnTerminate должен их ликвидировать.

Leonid Troyanovsky (2006-03-06 16:49:00) [2]

> isasa © (06.03.06 16:04) [44]
> С WM_COPYDATA Post не получится, только Send.

Влом проверять, но PostMessage with WM_COPYDATA, посылаемое
внутри процесса не должно принципиально отличаться от любого,
скажем, WM_USER. Т.е., посылаемые указатели будут всегда
действительны, однако гарантий того, что данные по этому
указателю не будут освобождены посылающим до окончания
обработки никто не даст.

--
Regards, LVT.

Leonid Troyanovsky (2006-03-06 16:42:00) [3]

> MegaVolt © (06.03.06 15:39) [43]

> оба метода потокобезопасны?

Рефрен: PostMessage (with GetMem & FreeMem in the work thread) -
асинхронная обработка.
SendMessage - синхронная обработка, с возможностью выполнения
любого кода в обработчике сообщения.

Обработка и того и другого происходит в контексте первичного
потока и является потокобезопасным. Однако, следует обратить
пристальное внимание на время жизни локальных переменных
(если ссылки на таковые присутствуют в параметрах сообщения),
которое критично для асинхронной обработки.

--
Regards, LVT.

isasa (2006-03-06 16:40:00) [4]
Хотя MSDN стало не таким категоричным
MSDN January 2000 WM_COPYDATA An application sends the WM_COPYDATA message to pass data to another application. To send this message, call the SendMessage function with the following parameters (do not call the PostMessage function). MSDN January 2006 WM_COPYDATAMessage -------------------------------------------------------------------------------- An application sends the WM_COPYDATA message to pass data to another application. Syntax To send this message, call the SendMessage function as follows.

GrayFace (2006-03-06 16:30:00) [5]
Я имелл ввиду метод из [20], а не [22]

isasa (2006-03-06 16:04:00) [6]
С WM_COPYDATA Post не получится, только Send.

MegaVolt (2006-03-06 15:39:00) [7]
>И просматривать 100Мб в блокноте. Ню-ню.

Зачем это? Специально заточенная прога просматривает этот файлик практически мгновенно :)

Из всего рассуждения я понял что и Post и Send подходят только один притормаживает поток а второй нет и возможна ситуация когда придёт сообщение от мёртвого потока. Но оба метода потокобезопасны?

Leonid Troyanovsky (2006-03-06 15:18:00) [8]

> GrayFace © (06.03.06 14:57) [40]

> Точнее, запуск - InterlockedIncrement, завершение - InterlockedDecrement
> и PostMessage гл. потоку. Главный поток вначале запускает
> потоков до предела, потом запукает потоки при получении
> сообщений.

ILI, IDI не обязательны. Конструктор и OnTerminate
выполняются в первичном потоке.

> или записывающем потоке. Но не WM_COPYDATA, а свое сообщение
> с указателем и размером в параметрах. Записывающий поток
> после записи будет освобождать память.

Почему "но"? Хочется асинхронности - Post.
Для синхронности SendMessage, а WM_COPYDATA - сгодится
для любых потоков, даже из других процессов.

--
Regards, LVT.

Leonid Troyanovsky (2006-03-06 15:12:00) [9]

> GrayFace © (06.03.06 14:57) [40]

> Не только в ранних. В Delphi 7 это тоже так.

Не совсем.
Начиная с D5 - очередь где-то в районе Application.Idle.

--
Regards, LVT.

GrayFace (2006-03-06 14:57:00) [10]
Leonid Troyanovsky © (03.03.06 13:15) [24]
Т.е., налицо все, что требуется от синхронизации.
Кстати, в ранних версиях дельфи она так и реализовывалась.
Не только в ранних. В Delphi 7 это тоже так.

MegaVolt
Обновлять статистику, по-моему, лучше всего методом [9]+[22]. В [22] написана ерунда про SendMessage, но алгоритм с Post описан верно и должен дать наилучший результат.

Leonid Troyanovsky © (03.03.06 13:43) [26]
Зачем в цикле? Запустил поток - inc, закончился поток - dec.
Т.е., если значение больше допустимого - не запускаем.
Точнее, запуск - InterlockedIncrement, завершение - InterlockedDecrement и PostMessage гл. потоку. Главный поток вначале запускает потоков до предела, потом запукает потоки при получении сообщений.

Запись в файл - точно так же - PostMessage и запись в главном или записывающем потоке. Но не WM_COPYDATA, а свое сообщение с указателем и размером в параметрах. Записывающий поток после записи будет освобождать память.

Crash Coredump (2006-03-06 14:42:00) [11]
А вот Google Desktop работает быстро и незаметно. Занимается куда как большей работой, чем составление списка файлов с атрибутами доступа.

Leonid Troyanovsky (2006-03-06 11:14:00) [12]

> MegaVolt © (06.03.06 10:22) [37]

> Список файлов доступных на доступ с их атрибутами.

И просматривать 100Мб в блокноте. Ню-ню.

> А задержку ты считаешь не совсем верно.

Ну, это лишь для девушек имеет большое значения.
Кста, исходные данные - твои. Про равномерность записи указаний не было.
Да и, пусть даже неравномерно - диск-то 1?

Юзер 4 сек переживет спокойно, если, конечно, не записывать
чрезмерного размера буферы (размера кластера вполне достаточно).
И нет тут особой разницы, сколько потоков пишут.

--
Regards, LVT.

MegaVolt (2006-03-06 10:22:00) [13]
>что там такого ценного в компьютере стоит 100Мб информации

Список файлов доступных на доступ с их атрибутами.

А задержку ты считаешь не совсем верно. Т.к. сохранение ты предлогаешь делать в одном потоке то есть шанс что все запущенные потоки станут в очередь на сохранение результатов. Т.е. допустим 10 потоков хотя бы по 1 Метру (а если предположить наихудший случай то и 2-5метров), уже получаем 10 метров а раз или 0,5 сек. Само собой юзер перетерпит эту задержку никуда не денется тем более на фоне тормозов софта от мелкософта вообще не много но что то мне очень не охота становится похожим на мелкософт :)

Leonid Troyanovsky (2006-03-03 18:28:00) [14]

> MegaVolt © (03.03.06 17:24) [35]

> или ещё что либо... Мне кажется это некрасиво.

Мне вообще непонятно, что там такого ценного в компьютере
стоит 100Мб информации (статистика излюбленных сочетаний символов
в файлах юзера?). И, зачем ему, собс-но, пялиться целых 20 мин
на все это, убиваясь из-за каких-то 4 сек (задержка 4/(20*60),
если человеческий глаз воспринимает 1/24 сек).

--
Regards, LVT.

MegaVolt (2006-03-03 17:24:00) [15]
>Т.е., ты не знаешь чем развлечь юзера в течении 4 сек?

Весь процесс занимает минут 20 за это время будет собрано 200-300 кусков информации которые в сумме дадут 100Метров. Если запрячь эти 100Метров писать главный поток то форма будет недоступна пользователю в общей сумме 4 сек. Т.е. пользователь может наблюдать рывки например при перетаскивании или замедленную реакцию на нажатие каких либо контролов или ещё что либо... Мне кажется это некрасиво.

Leonid Troyanovsky (2006-03-03 16:56:00) [16]

> MegaVolt © (03.03.06 16:40) [33]

> Файликов будет штук 200-300. Суммарный объём под 100Мег
> Т.е. например у меня на машине запись 100Мег это 4 секунды.
> Значит пользовательское приложение за время работы будет
> будет в сумме недоступно 4 секунды. Впринципе немного но
> заметно должно быть.

Т.е., ты не знаешь чем развлечь юзера в течении 4 сек?
Попроси его следить за красной (желтой) лампочкой на корпусе.

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

--
Regards, LVT.

MegaVolt (2006-03-03 16:40:00) [17]
>Маленькие - это какие? И куча - это сколько?

Файликов будет штук 200-300. Суммарный объём под 100Мег
Т.е. например у меня на машине запись 100Мег это 4 секунды. Значит пользовательское приложение за время работы будет будет в сумме недоступно 4 секунды. Впринципе немного но заметно должно быть.

Собирать в кучу неохота потому что для этого понадобится ещё столько же места на венике. Некрасиво однако.

Leonid Troyanovsky (2006-03-03 16:27:00) [18]

> MegaVolt © (03.03.06 16:10) [31]

> файлик. И потом отдельно собирать его из кучи маленьких
> неохота.

Маленькие - это какие? И куча - это сколько?
Вполне возможно, что всю запись в файл можно сделать
в первичном потоке совершенно ненапряжно для пользователя.
Например, в обработчике WM_COPYDATA формы.

--
Regards, LVT.

MegaVolt (2006-03-03 16:10:00) [19]
>Ну, во-первых, почему главный, когда сохранять будет каждый.

Понял. Это не совсем подходит мне нужен один результируюющий файлик. И потом отдельно собирать его из кучи маленьких неохота.

>Во-вторых, чудес не бывает...

Знаю. Один лишний поток погоды не сделает.

>кстати, непонятно, почему этот процесс нуждается в присутствии пользователя

Процесс не нуждается. Но пользователю желательно видеть что сейчас сканируется, видеть что прога не висит, да и остановить её тоже бывает нужно.

Leonid Troyanovsky (2006-03-03 15:58:00) [20]

> MegaVolt © (03.03.06 14:38) [28]

> Так проблема не в том куда писать а в том что запись занимает
> время. Т.е. мой главный поток вместо работы с пользователем
> будет заниматся сохранением результатов и это явно будет

Ну, во-первых, почему главный, когда сохранять будет каждый.
Во-вторых, чудес не бывает - больше потоков, меньше процессорного
времени достанется каждому (при равных приоритетах).

Т.е., все равно нужен компромисс между степенью интерактивности и
объемом данных сканирования (кстати, непонятно, почему этот
процесс нуждается в присутствии пользователя).

--
Regards, LVT.

Страницы: 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »