Метод обратного вызова?

[Ins]

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

Да дело не в этом... Оно может 99 раз пройти безболезненно (если потоки несмотря на отсутствие синхронизации не обращались к менеджеру одновременно), а на сотый - зависнуть. А на пятисотый - рухнуть вместе со всем приложением Это примерно то же самое, что обращаться из потоков к VCL без синхронизации - несколько раз пройдет безболезненно но рано или поздно все сломается. А обращения к менеджеру памяти и без твоего явного участия происходят например - при использовании типа string

[Altera]

Ясно. Значит createThread вообще лучше не использовать? А ещё какие исключения есть?

Слушай, а почему тогда я нигде про это не встречал. Ведь я не одну книгу то прочёл по Delphi. Не знаю, не длжен плантровщик глючить по идее.

А что ели в много потоковой программе сразу при запуске IsMultiThread выставить в true?

[Ins]

Ясно. Значит createThread вообще лучше не использовать? А ещё какие исключения есть?

Да, в Delphi вместо него нужно использовать BeginThread. В принципе почти каждый язык программирования предлагает свою обертку над CreateThread, учитывая свою специфику. Какие еще исключения? Да много на самом деле. SuspendThread/ResumeThread тоже не нужно использовать, даже их обертки (TThread.Suspend/TThread.Resume) если только не сразу после создания остановленного потока, так как представь что будет, если поток заблокировал менеджер памяти, а в этот момент его остановили. Никто уже к менеджеру памяти не достучится TerminateThread - вообще ужасная функция, утечку памяти в 1 мегабайт нравится получать?

Слушай, а почему тогда я нигде про это не встречал. Ведь я не одну книгу то прочёл по Delphi. Не знаю, не длжен плантровщик глючить по идее.

Нельзя объять необъятное То, что ты прочел более одной книжки не говорит о том, что теперь тебе все известно. Ну а именно про опасности CreateThread, правда в применении к C++, написано у Рихтера. А насчет Delphi на различных форумах не раз твердилось... И дело не в планировщике, функция то работает правильно, но откуда Windows что-то знает о дельфийском менеджере памяти, который в целях оптимизации при старте программы запусается в однопоточном режиме?

А что ели в много потоковой программе сразу при запуске IsMultiThread выставить в true?

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

[Altera]

Сообщение от Ins

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

Ок, просто сам вопрос интересен. А как же не использовать функции остановки/продолжения потока? Может те места, где поток явно выделяет/освобождает память и suspend/ResumeThread брать в критические секции?

[Ins]

Может те места, где поток явно выделяет/освобождает память и suspend/ResumeThread брать в критические секции?

Так в этом и проблема, менеджер памяти использует критические секции. Ну вот тебе сценарий: поток 2 выделяя память осуществляет вход в критическую секцию, поток 1 его останавливает сразу после этого, так как теперь выйти из критической секции поток 2 не сможет, а для выделения памяти в других потоках нужно дождаться осбобождения крит. секции, попытка выделить память в любом потоке приведет к деадлоку.

Как останавливать поток? А никак, читай что пишет MSDN про эти функции - НЕ ИСПОЛЬЗОВАТЬ для синхронизации, эти функции предназначены только для отладчиков. Для синхронизации использовать предназначенные для этого инструменты - объекты синхронизации и Wait-функции

This function is primarily designed for use by debuggers. It is not intended to be used for thread synchronization. Calling SuspendThread on a thread that owns a synchronization object, such as a mutex or critical section, can lead to a deadlock if the calling thread tries to obtain a synchronization object owned by a suspended thread. To avoid this situation, a thread within an application that is not a debugger should signal the other thread to suspend itself. The target thread must be designed to watch for this signal and respond appropriately.

В общем, нельзя принудительно останавливать другой поток, он должен сам инициировать переход в режим ожидания

[Altera]

Можно манипулировать потоком по средствам сообщений. Т.е. вызывать getMessage в потоке и делать подходящие действия. В общем я учту это.

Кстати, я имел ввиду взять в критические секции не только обращения к планировщику но и suspend/resumeThread

[Ins]

Кстати, я имел ввиду взять в критические секции не только обращения к планировщику но и suspend/resumeThread

И что это даст?

[Altera]

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

[Ins]

Какой планировщик? Планировщик потоков Windows? Каким образом он может быть заблокирован?

[Altera]

Сообщение от Ins

Какой планировщик? Планировщик потоков Windows? Каким образом он может быть заблокирован?

Блин, планировщик памяти.