Почему при старте зависает поток?

Откуда сведения о том, что зависает? Долго HTTPSend.HTTPMethod('GET', Site); обрабатывается? Так это нормально. 

Poseidon, при старте программа полностю зависает секунд на 5-10, из-за чего?

Application.ProcessMessage попробуй. Из-за чего? Может из-за цикла, может из-за Get.

А где именно должен быть Application.ProcessMessages?

Не помогает.

в потоке имхо надо...

а где именно в потоке?

Тут нужно смотреть код. Может в OnCreate что-то "тяжелое" выполняется, может еще что. Так просто "на глаз" сказать сложно.

при чем сдесь OnCreate? Они же не при запуске программы зависает. А когда поток запускаю.

где то между repeat  &  until (если не http затыка)

не помогает

Я не совсем понял изначально эту фразу 

"При старте" - это на какой строке? Что показывает отладка? Вполне возможно что поток стартует быстро, и останавливается на HTTPSend.HTTPMethod. Я уже писал, "зависание" на HTTPSend вполне объяснимо.

А как с этим бороться?

интернет мощнее

я бы первым делом избавился от synchronize
совсем
(есть postmessage, events и можно общаться просто через переменные/поля)
synchronize - главный источник проблем начинающих многопоточников

А как без синхронизации сделать, я не много не понял.

я же ключевые слова давал 
или хотя бы так:
http://codeguide.ru/peredacha-informatsii-...oka-delphi.html
(только postmessage вместо sendmessage)

С Synchronize запись в Memo делается двумя строчками кода. Извращаться для данной задачи с помощью PostMessage - это как в Питер из Москвы через Владивосток. Можно, но не целесообразно. При любом раскладе, даже с помощью PostMessage, мы передаем управление в VCL-поток для отрисовки Memo. Так почему же не воспользоваться специально предназначенным для этого Synchronize? Ну а общение через переменные - это вообще аут. А как эти переменные в VCL-потоке считывать? Цикл крутить? Таймер задействовать? Synchronize тут правильно использовано.

ну так как мне правильно сделать? В чем у меня ошибка?

сначала надо определится в каком месте виснет 

В 17-ой строке у тебя ошибка. А если серьёзно - загружаешь свой проект, и пошагово смотришь по нажатию F8, где же он тормозит. Предварительно расставив бряки.


Это сообщение отредактировал(а) CynicRus - 14.4.2014, 21:01

а что не так в 17 строке?

Это древняя шутка про отсутствие телепатических способностей. К делу отношения не имеет. Просто посмотри под отладчиком.

просто не очень понимаю как пользоватся отладчиком....

Добавлено через 1 минуту и 50 секунд

UKRtortik, проверил свою ссылку - не работает, весь сайт накрылся - а вы что молчите?? вот, держите копию:
http://webcache.googleusercontent.com/sear...oka-delphi.html

а для начала я бы тупо закомментировал строку с synchronize и посмотрел бы на быстродействие

Рoseidon> С Synchronize запись в Memo делается двумя строчками кода. 

точно. на этом все и ловятся

Рoseidon> При любом раскладе, даже с помощью PostMessage, мы передаем управление в VCL-поток для отрисовки Memo. 

НЕТ же! асинхронное сообщение передаёт данные, а не управление. как и переменные.
передать управление из потока в поток вообще невозможно, хотя можно организовать видимость этого, тупо приостановив "вызывающий" поток до завершения действия в "вызываемом", что и делает synchronize

Рoseidon> Ну а общение через переменные - это вообще аут. А как эти переменные в VCL-потоке считывать? Цикл крутить? 

не "аут", а банальное низкоуровневое решение
вы наверное удивитесь, но окно принимает/обрабатывает сообщения тоже крутя цикл
согласен, что подобный низкоуровневый код лучше куда-то заинкапсулировать, но раз борланд не справился...
можно юзать OmniThreadLibrary или AsyncCalls еще

Рoseidon> таймер использовать?

проще sleep, хотя я бы предпочел CreateEvent и WaitForSingleObject

так уж вышло, что "из коробки" synchronize оказался единственным удобным средством для передачи сообщений VCL-потоку
но эта штука специфичная. гораздо полезнее во многих случаях был бы "Asynchronize" - то есть то же самое, но без приостановки потока (т. е. без удара по быстродействию)
вот тут недавно чел пострадал от synchronize: http://forum.vingrad.ru/index.php?showtopi...t&p=2604306

Это сообщение отредактировал(а) PointerToNil - 14.4.2014, 22:15

Вот, изучай.

 
По твоему подобные решения лучше Synchronize? Может вообще тогда на ассамблере писать, чо уж там?

Poseidon> По твоему подобные решения лучше Synchronize?

возможно, лучшее решение - Asynchronize, но его пока нет (и мне не нужно, а то мог бы попробовать набросать)

врожденный порок (для кого-то - фича) synchronize никуда не денется: он тупо останавливает вызывающий поток! кому это нужно? мне нет, поэтому любое решение, этого не делающее - для меня лучше

Poseidon> Может вообще тогда на ассамблере писать, чо уж там?

если речь о функции-утилите, которая пишется 1 раз, а используется в тысяче мест - то многие так и делают (в применении к потокам - смысла в ассемблере нет)

Это сообщение отредактировал(а) PointerToNil - 14.4.2014, 23:08

Это дает гарантию, что к общему ресурсу (в частности к VCL-объекту) имеет доступ только один поток. Видимо PointerToNil не сталкивался с ситуациями, когда пока один поток перепрыгнет на одну строку, второй поток уже считает данные и изменит их. Synchronize для того и задуман, что бы гарантировать доступ только одного потока. Если у нас ситуация, когда один поток должен работать с данными, которые высчитываются в другом потоке, то как можно гарантировать правильность расчетов?

Poseidon, у меня просто слов нет, чтобы выразить...
конечно, к VCL-объекту имеет доступ только один поток - поток VCL!!! не в вызывающем же потоке исполняется метод-параметр synchronize!
если возникли сомнения: http://forum.vingrad.ru/index.php?showtopi...st&p=480368
и подробнее: http://www.delphiplus.org/articles/delphi/...s_programs.html
вот только зачем вызывающий поток-то для этого останавливать? 
это даже гарантию немедленного исполнения требуемого действия не может дать - поток VCL чем-то своим еще может быть занят
хотя на однопроцессорных и однотредовых машинах эта остановка еще имела смысл (ускорить запуск требуемого метода), но на многопроцессорных смысла уже не осталось
очевидно, это - реликт, оставшийся от старой эпохи (хотя скорее всего могли и тогда более правильно это сделать)

а вот и возможное решение (из второй ссылки):
По сравнению с Delphi 7 в классы потоков Delphi 2009 внесено много изменений. Прежде всего, в класс TThread добавлена группа перегруженных методов Queue, которые позволяют синхронизировать вызов методов с главным потоком в неблокирующем режиме.

Poseidon> Видимо PointerToNil не сталкивался с ситуациями, когда пока один поток перепрыгнет на одну строку, второй поток уже считает данные и изменит их

конечно нет, как же это, совсем без критических секций что ли?? (а для простых типов данных, <=4 байта - есть interlocked* функции)

Poseidon>Если у нас ситуация, когда один поток должен работать с данными, которые высчитываются в другом потоке, то как можно гарантировать правильность расчетов?

ну как бы сразу напрашивается переменные/поля на 3 состояния, сигнализирующие о том, что обработка данной порции данных еще не начата/начата/уже закончена или 2 переменные - счетчики числа взятых на обработку элементов и числа уже обработанных (причем синхронизировать доступ к ним (interlocked*) нужно только для операции установки состояния "взято на обработку" или увеличения счетчика взятых на обработку, только между несколькими потоками-обработчиками и только в случае, если их несколько, а VCL-поток волен читать их в любой момент) - но для кого-то это может показаться слишком простым и низкоуровневым, [sarcasm] тут же без пары крутых специальных классов с дюжиной методов не обойтись [/sarcasm] 
не любите циклы с ожиданием? используйте CreateEvent, (Re)SetEvent и WaitFor(Single|Multiple)Object

Это сообщение отредактировал(а) PointerToNil - 15.4.2014, 03:23

 А если ситуация, когда потоку надо обратиться к VCL несколько раз подряд? Как без блокируещего метода и без бубна гарантировать, что предыдущее обращание завершилось?

Т.е. если один поток отрабатывает критическую секцию, второй поток не ждет на входе в нее? Второй поток не простаивает? Это чем-то принципиально отличается от Synchronize?

Ну да, реально проще наворотить с три короба кода, придумать крутые алгоритмы с переменными, сигнализированием, счетчиками, но ни за что не пользоваться Synchronize. А в чем разница, или поток будет крутить в холостую цикл, ожидая когда же нужная переменная примет нужное значение, что бы пойти дальше, или поток остановится, ожидая Synchronize?

Это не решение, а один из вариантов. Если потоку надо "вбросить" данные в VCL и идти дальше (как в случае автора), то Queue подойдет. А если потоку надо работать с данными VCL, то тут нужна гарантия что кто-то другой (поток или даже сам пользователь) не поменял эти данные в процессе.

А теперь самое интересное. У UKRtortik в Synchronize одна строчка кода, которая обрабатывается за долю секунды. Неужели блокировка потока на эту долю секунды и есть то самое "зависание" о котором пишет UKRtortik? Неужели если мы отправим в VCL неблокирующее сообщение вместо Synchronize, то поток не "зависнет"? Там по коду отчетливо видно, что поток посылает Get в сеть и ждет ответ. Вот это ожидание и есть причина. А Synchronize там вообще не при чем.

Модератор: Давайте вернёмся к теме обсуждения.

F7 & F8

Poseidon> А если ситуация, когда потоку надо обратиться к VCL несколько раз подряд? Как без блокируещего метода и без бубна гарантировать, что предыдущее обращание завершилось?
это гарантируется тупо тем, что поток VCL только один и, естественно, обращения к нему выстраиваются в очередь (ну загляни в classes.pas что ли уже, если ссылки tl;dr)

Poseidon> Т.е. если один поток отрабатывает критическую секцию, второй поток не ждет на входе в нее? Второй поток не простаивает? Это чем-то принципиально отличается от Synchronize?
да. отличается по области применения. критические секции (или атомарный доступ к предложенным мной переменным-признакам или счетчикам) нужны для сериализации (очередизации) доступа к данным среди потоков-копий из одной группы/пула - они могут за эти данные конкурировать, например, пытаться одновременно "забрать" себе на обработку один очередной необработанный блок.
а в ситуации как у ТС, когда "рабочий" поток уже обработал блок данных и он ему больше не нужен, поток следующего этапа (занимающийся выводом) может его спокойно (если этот поток в одном экземпляре) забирать, он должен только о его готовности узнать либо по переменной-признаку, либо по сообщению в своей очереди. без конкуренции потоков синхронизация гораздо проще (нет толкотни соседей по очереди) 

Poseidon> Ну да, реально проще наворотить с три короба кода, придумать крутые алгоритмы с переменными, сигнализированием, счетчиками
да никаких "алгоритмов" тут нет! самое сложное тут - это ну а написав "с три короба" лишь один раз, нормальный программист обернет это как следует, чтобы в другой раз просто вызвать метод/функцию
(обычно это успевают сделать за нас еще в Микрософте/Борлакадеро, и там у них внутри те же примитивные переменные и циклы)

Poseidon> А в чем разница, или поток будет крутить в холостую цикл, ожидая когда же нужная переменная примет нужное значение, что бы пойти дальше, или поток остановится, ожидая Synchronize?
предполагается, что "крутить цикл" будет ожидающий данных (пока еще не готовых) поток второго этапа (вывода и т.п.), а останавливать по Synchronize я не хочу потоки первого этапа ("рабочие"), к которым навалом других сырых данных в очереди ещё стоит (если вдруг наоборот, в очереди на вывод скопление образуется, то и крутить вхолостую ничего не придется)

Poseidon>А если потоку надо работать с данными VCL, то тут нужна гарантия...
да что же это такое то?!?! с данными VCL номинально разрешено работать только потоку VCL. к счастью, он у нас только один
гарантий же от глупости программиста никакие волшебные классы/методы/функции никогда не дадут
в частности, Synchronize блокирует только свой собственный поток (думаете, авторы VCL предполагали, что программист, только что послушно выполнив их рекомендации и вызвав правильный метод, может ТУТ ЖЕ СРАЗУ уйти в отрыв и с горя полезть в VCL напрямую, поэтому и решили это дело заблокировать?!? сорри за эмоции, если что) 
при этом Synchronize ничуть НЕ блокирует ВСЕ остальные потоки (вообще по-хорошему только сам поток может себя "поставить на паузу", как и закончить, хотя через winapi... но это не рекомендуется)

Модератор: Давайте вернёмся к теме обсуждения.
а без тредстартера основная тема все равно пока WaitingForSingleObject

Это сообщение отредактировал(а) PointerToNil - 15.4.2014, 12:16

Отлично. Поток отдает VCL данные, что бы VCL их применил, и идет дальше. А дальше нужно эти данные прочитать. Поток считывает данные, наивно предполагая, что предыдущий код их изменил. Но вот незадача, наредивый пользователь влез своими руками и поменил что-то. И получилось у нас, что поток считал уже не те данные, которые ожидались. Ах да, можно же нагородить кучу проверок, флагов, блокировок, но Synchronize использовать ну никак нельзя.

"Это" - 10 строк кода в примитивной реализации. Synchronize займет одну.

Нормальные программисты уже обернули подобные велосипеды в Synchronize, Queue прочие методы TThread. Но богата земля русская умельцами, которые неприемлят буржуйские традиции.

Очень хочется увидеть код, который через WaitingForSingleObject заставит поток, который отправляет Get запрос, выполнятся без задержек. Пока это больше похоже на пустой треп. Автор стросил причину, ему причину указали. И эта причина совершенно не в использовании Synchronize.

!  Poseidon

Обсуждение целесообразности использования Synchronize в данной теме является нарушением пункта 9 Правил форума. Сообщения в данной теме, являющиеся ответами на мои цитаты, будут расценены как провокация к нарушению Правил и будут удалены на основании пункта 3.

PointerToNil, если есть желание обсудить никчемность Synchronize, можешь создать для этого отдельную тему.

Извините я возможно не заметил, ну где мне указали причину?

 

а что с этим делать?

Tесли HTTPSend - это Indy, то у ней может быть свой механизм потоков, с странным поведением которого вы и сталкиваетесь. 

 

этого что недостаточно?

А покажи пинг того ресурса, куда отправляется Get.

Poseidon, я все же сделаю еще одну попытку объяснить недопонятое, потому, что иначе затраченные нами обоими на этот разговор усилия оказываются совсем бесполезными. А так остаётся маленькая надежда.

Те приведенные 10 строк - вовсе не замена synchronize, они нужны для совсем другого случая - а именно, для сериализации доступа к данным между конкурирующими за них потоками (перечитайте абзац, где упоминается конкуренция). Там synchronize не применим никак, так как разбираться друг с другом должны несколько рабочих (неглавных) потоков! (обычно их число = числу ядер или *2 для гипертрединговой архитектуры). Участвует ли в этой конкуренции еще и главный (VCL) поток или нет - значения не имеет. 
Interlocked* функции (пример в тех 10 строках) - облегченная замена критическим секциям для случаев, когда нужна одноразовая атомарная операция с переменной/полем простого типа.

А вот TThread.Queue - отличный вариант (как замена synchronize), я как раз за него! (если он есть в вашей версии дельфей)

"без тредстартера основная тема все равно пока WaitingForSingleObject" - перевожу на русский: без тредстартера основная тема все равно пока зависла в ожидании одного объекта, т.е. тредстартера (это была попытка пошутить)

BTW, собрал и запустил код тредстартера - никакие "подвисания" не проявились

Это сообщение отредактировал(а) PointerToNil - 17.4.2014, 12:58

Яж тебе говорил - под отладчиком пошагово посмотри, где у тебя тормозит. Как пользоваться отладчиком? Можно заценить тут.

а как понять из-за чего зависает в открадчике? Зависать начинает на этой строке:

UKRtortik, тебе нужно найти строку в коде программы, исполнение которой тормозит
1 поставь breakpoint (F5) на первой после begin строке TNewThread.Execute
2 запусти программу (F9), в ней - свой тред, дождись срабатывания брейкпоинта (открытия экрана дельфи)
3 теперь жми F8 и следи за задержкой (между скрытием и новым появлением экрана дельфей, обычно это мерцание даже не успеваешь заметить) - многократно, пока не найдешь (или до выхода из метода)

PointerToNil, что-то я соровно так и не смог разобратся....