У меня один коротенький поток вызывается главным окном каждые 2 секунды. Логично освобождать из-под него память. Однако если FreeOnTerminate = true,  то возникает исключение примерно такого содержания:
"... raised exception class EOSError with message 'System Error. Code: 6. Неверный дескриптор'". Прямо так по-русски и пишет - неверный дескриптор.
В классе потока есть три перменные, но я вроде к ним нигде кроме как из самого потока не обращаюсь, тем более после его завершения.
В чём может быть проблема?
Что это за класс EOSError?

А после того, как отрабатывает, Вы его заново создаете?

Создаю его по событию таймера. Событие возникает каждые 3 секунды  (а не 2 как раньше написал, извиняюсь). За это время он успевает завершиться.

Но это наверно неважно, так как возникает исключение на первом же экземпляре потока (только не знаю именно в момент завершения или нет).

А вообще если он не успеет завершиться за 3 сек. И по таймеру будет создан второй поток, он не будет конфликтоватьс первым? Или это будет неправильно?

Это сообщение отредактировал(а) ksili - 12.3.2007, 11:13

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

Код, конечно, в таких вопросах ОБЯЗАТЕЛЬНО надо приводить... Навскидку можно предположить, что при завершении потока вызывается последовательность Thread1->Terminate и затем Thread1->Free (или как-то аналогично). При установленном свойстве FreeOnTerminate = true вторая команда фактически будет освобождать уже автоматически особожденный (при Terminate) участок памяти, что приводит к AV.

Посмотрел в диспетчере задач без FreeOnTerminate = true. Вроде всё нормально один процесс создаётся и через некоторое время убивается. Память тоже освобождается и выделяется (больше не становится). Так что ложная тревога. Всем спасибо за внимание

А причем тут процессы  Речь идет об уничтожении объекта класса после завершения процесса. То есть у Вас (если Вы конечно не уничтожаете  объект сами ) будет накапливаться утечка памяти.
Правда по завершению программы конечно все освободится ( WIn32 как никак  ).  Но согласитесь, что такой подход некрасив : new без delete

Добавлено @ 13:21 

Это Вы по диспетчеру задач определили ? Мда. А Вы не пробовали  спросить мнение на этот счет у CodeGuard? Думаю, он будет против. 

Так значит правильная последовательность работы с потоком примерно такая:

?

Если так написать, то память будет освобождаться и на флаг FreeOnTerminate можно не обращать внимание? Я правильно понял?

Это сообщение отредактировал(а) ksili - 13.3.2007, 07:37

Для потока с FreeOnTerminate = true; завершение делается так:

Видимо если FreeOnTerminate = false; надо добавить delete td;

Идея то правильная.  И тут все будет очищаться правильно. Только в с логикой напряги.  Вы запускаете поток, а потом тормозите основной до момента, пока не выполнится дочерний. Смысл? Не проще тогда выполнить все действия в основном потоке? Все равно при работе дочернего он простаивает  
Я пока не могу понять одно. Почему у Вас не работает это ?

Вы случаем после этих строчек не пытаетесь написать что-то вроде

или то, что  pandrew указал? Этого делать ни в коем случае нельзя. К моменту  обращения  к объекту td после того как уже вызван  Resume() поток может выполнится, а объект, соответственно, уничтожен  и Вы будете обращаться к несуществуещему объекту

Добавлено @ 13:17 

Грубая ошибка. Во-первых к моменту вызова Terminate поток может уже завершиться и td уничтожиться. Во-вторых, даже если поток еще работает, то он может успеть завершиться и уничтожиться после Terminate, но  до вызова  WaitFor.

Сейчас уже кода перед глазами нет, завтра погляжу повнимательнее и отвечу.
А почему нельзя после Resume() писать WaitFor()? Когда вообще тогда WaitFor() писать нужно?

ksili, сможешь аргументировать применение потоков в своей задаче?

Я согласен, что WaitFor использовать в основном потоке неправильно, так как это тормозит всю прогу и сводит на нет все преимущество от использования потоков.

Теперь попробую аргументировать применение потоков в моей задаче.
В системе есть много COM-портов. Программа должна опрашивать те которые инициализированы (сейчас при отладке экспериментирую только с одним) на предмет того, что на них что-то поступило. Если поступило, то она сохраняет инфу об этом в специальной таблице БД. 
Есть ещё несколько потоков, которые периодически смотрят в эту таблицу и если там что-то есть, то отрабатывают это событие.

То событие таймера (раз в 3 сек)  о котором я говорил выше, перебирает все порты и запускает для каждого инициализированного порта поток, к-рый его опрашивает.

В общем эти действия (опрос порта и обработка поступившей  инфы) должна происходить не в основном потоке (реально портов будет не меньше 40), чтобы я во время всего этого мог работать с программой: инициализировать порт, освободить порт, смотреть журналы портов, смотреть текущую информацию о каналах  и т.д.

Я сейчас уже подумал, что правильнее будет не создавать эти потоки каждые 3 секунды, а создавать поток на каждый инициализированный порт, который будет его опрашивать постоянно:



Это сообщение отредактировал(а) ksili - 14.3.2007, 06:01

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

сам поток в таком виде работает нормально:

while(!Terminated)
        {

               if(WaitCommEvent(Form1->hCom,&dwCommEvent,NULL))               

                if(ClearCommError(Form1->hCom,&dwError,&COMSTAT))
                    dwRead=COMSTAT.cbInQue;
                                  {
                                          while (dwRead)
                                       {
        ReadFile(Form1-hCom   lpBuffer1,dwRead,lpNumberOfBytesWritten, NULL);
                        
                        Form1->Nsect=Form1->Data.RecByte1
                        Form1->Fh=(Form1->Data.RecByte2)+((Form1->Data.RecByte3)*255);
                                        
                        Form1->Label20->Caption=IntToStr(Form1->Data.RecByte1);
                        Form1->Label21->Caption=IntToStr(Form1->Data.RecByte2);
                        Form1->Label23->Caption=IntToStr(Form1->Data.RecByte3);
                        Form1->Label24->Caption=IntToStr(Form1->Fh);
                          
                                         }
                                   }
        }

но при попытке его подвесить из основного потока все виснет. 

Всё, что обращается к основной форме


надо поместить в отдельную функцию класса потока и вызывать её при помощи метода потока Synchronize. посмотри хелп на Synchronize

Так ведь Synchronize нужна, чтобы предотвратить одновременный доступ к одному и тому же объекту. В моей программе только поток чтения обращается к объектам

Form1->Nsect=Form1->Data.RecByte1
                        Form1->Fh=(Form1->Data.RecByte2)+((Form1->Data.RecByte3)*255);
                                        
                        Form1->Label20->Caption=IntToStr(Form1->Data.RecByte1);
                        Form1->Label21->Caption=IntToStr(Form1->Data.RecByte2);
                        Form1->Label23->Caption=IntToStr(Form1->Data.RecByte3);
                        Form1->Label24->Caption=IntToStr(Form1->Fh); 



, а чтобы не случилось проблем я и пытаюсь притормаживать поток чтения.

Synchronize нужна всегда, когда обраащешься к визуальным компонентам (Form, Label и т.д.) потому что есть ещё основной поток твоей программы, и когда он там к чему обратится неизвестно (событий же куча). Поэтому надо синхронизировать. Попрбуй сделать как я написал, может висяки исчезнут.
Да и здесь на форуме есть несколько тем, где это более-менее описано. А к данной теме синхронизация очень отдалённо относится

Сделал синхронизацию всех обращений к компонентам VCL из потока, но никакого эффекта - пока в порт не поступают данные программа также виснет при попытке передавать данные в порт. 
Согласен СИнхронизацию не обсуждаем, речь о работе с потоками.

Фишка еще вот в чем -
когда убираю функции Suspend и Resume, то все работает нормально - и чтение идет и запись, но как-то это не красиво: при записи в порт надо остановить чтение. Пока не придумал как.

Если Вы используете FreeOnTerminate = true, то после Resume() вообще обращаться к как либо к объекту TThread  обращаться  опасно. К тому времени, когда Вы  попытаесь обратиться, вполне возможно, что он уже завершился и в о


Вольный перевод


Что касается использования  WaiteFor, то все очень просто.   WaitFor как раз должен следовать за Resume, но не следующей сточкой 

То есть в отличие от вашего кода мы имеем участок, когда идет паралельное выполнение в основном и дочернем потоке. А WaiteFor() в данном случае приминяется для синхронизации этих потоков. Мы же не знаем, кто завершит свой код раньше основной поток или дочерний. Но такое поведене справедливо при FreeOnTerminate= false

Читаем: 
TThread::Terminate
Signals the thread to terminate by setting the Terminated property

Так что утверждение про разрушение td между вызовами сомнительно.
Я всегда пишу потоки как бесконечную петлю обработки (иначе не понимаю зачем они нужны), поэтому самозавершения потоков у меня не бывает. Бывают правда исключение в потоковой функции, которые приводят к завершению, если не обрабатываются. Но я всегда рулю всеми потоками из главного без проблем по указанному варианту.
В вашей логике те же грабли: любой вызов td может быть некорректен, ибо td уже разрушен

Причем тут это? Вы вводную читали?

Поток успевает завершиться сам, а не принудительно через Terminate. И таких задач, где нет бесконечного цикла  навалом. Если Вы не встречали в своей практике, это еще не значит, что их нет. 
Так что Ваш код для данного случаЯ ошибочен. Поток во-первых может завершиться сам до вызова Terminate. 
Ну а если Вы этот же код используете у себя и при этом у вас есть цикл с проверкой Terminated и FreeOnTerminate == true, то код  


опасен все равно. Потому что есть вероятность, что Вы можете схлопотать эксепшен на вызове WaitFor(). Надеяться на то, что между вызовами Terminate и WaitFor объект не успеет разрушится, неразумно. Если уж очень хочется обнулить td то логичнее и безопаснее смотрелось бы
 


 
 

У меня основной целью было не обнулить td, а чтобы не росла занимаемая программой память из-за постоянно создаваемых потоков.
В принципе я уже переделал основные потоки, к-рые создаются моей программой, по типу бесконечной петли обработки, но есть ещё поток, который создаётся время от времени.
 
О, прямо сейчас придумал! А если и этот поток делать как бесконечную петлю обработки, но, поскольку он должен выполняться эпизодически, ввести дополнительное условие:

А флаг просто менять из того потока, который должен активировать этот

тебе не надо ничего придумывать. вместо этого лучше прочитай пару-тройку статей про потоки и синхронизацию.

твой поток можно сделать, например, так:


когда нужно, чтобы рабочий поток выполнил "...", в основном потоке делаешь:

Да, суть та же, только писанины больше. Всё равно же, все эти апишные функции (как впрочем и все), по сути - обёртки для обычных mov eax, ecx   (в нашем случае - mov flag, 1). А, по-моему, чем проще, тем надёжнее и быстрее