Зависание потоков при обращени к ListBox

@calculon · Регистрация: 18.07.2012

Студворк — интернет-сервис помощи студентам

Столкнулся со следующей проблемой. Есть основная форма приложения. Есть рабочие потоки. В качестве логера им передается адрес ListBox'a на основной форме. При входе в поток и выходе из него в лог вносятся соответсвующие записи (при этом разумеется используются критические секции). Так вот если пытаться корректно завершить работу потока передачей ему соответсвующего флага и ждать его через WaitForSingleObject() то программа попросту виснет. Дебаг показал что происходит это это при входе в pListBox->Items->Add(). Если эту строчку убрать все работает как часы. Есть ли соображения по этому поводу? Да, заранее всем спасибо...

@Avazart · 28.08.2012, 01:29

Используй класс TThread

Подробней в этой книге http://www.ozon.ru/context/detail/id/5009785/

@ree4 · 28.08.2012, 05:12

из потока нельзя обращаться на прямую к VCL, поэтому и висяки

@calculon · 28.08.2012, 05:34 **[ТС]**

[QUOTE=Avazart;3395273]Используй класс TThread

А чем плох обычный вызов CreateThread? TThread ведь просто обертка...

@Avazart · 28.08.2012, 14:59

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

А чем плох обычный вызов CreateThread? TThread ведь просто обертка...

Этим

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

из потока нельзя обращаться на прямую к VCL, поэтому и висяки

В TThread есть для этого синхронизация... да и просто удобнее...

( Точнее не VCL, а видимым компонентам, от TWinControl )

@BRcr · 28.08.2012, 17:31

Avazart, а не в курсе, почему начиная именно с TWinControl? Что там такого ввели, что возникают конфликты доступа?

@Avazart · 28.08.2012, 17:37

Ну TWinControl этож базовый всех оконных? Или я не прав?

Добавлено через 4 минуты
Хотя видимо не прав... - TControl

@BRcr · 28.08.2012, 18:17

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

А откуда знаешь, что синхронизация нужна только для потомков TWinControl, а не для всех объектов VCL?

@Avazart · 28.08.2012, 18:24

Архангелький пишит для всех визуальных...

Оно то по логике и понятно что для всего, что участвует в перерисовке окна...

Добавлено через 3 минуты
Из справки

TControl

Controls are visual components, meaning the user can see them and possibly interact with them at runtime. All controls have properties, methods, and events that describe aspects of their appearance, such as the position of the control, the cursor or hint associated with the control, methods to paint or move the control, and events that respond to user actions.

TControl has many protected properties and methods that are used or published by its descendants.

@BRcr · 28.08.2012, 18:34

Да, TControl вводит функционал для работы с некими визуальными компонентами, однако там нет и намека на работу с оконными элементами операционки.
Еще вопрос, что Архангельский под этим подразумевает...

@volvo · 28.08.2012, 18:41

Синхронизация нужна для non thread-safe объектов. TControl еще является потокобезопасным. И, соответственно, его наследники, если написаны правильно, могут быть потокобезопасны (тогда с ними можно работать без Synchronize).

А вот TWinControl уже сам не thread-safe, то есть, все его потомки по определению не могут быть безопасны => только с синхронизацией.

@Avazart · 28.08.2012, 18:52

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

Еще вопрос, что Архангельский под этим подразумевает...

Походу я ошибся... не в Архангельском видел( пересмотрел не там такого )

Коментарии при создании наследника TThread

C++
1
2
3
4
5
6
7
8
9
10
11
//   Important: Methods and properties of objects in VCL can only be
//   used in a method called using Synchronize, for example:
//
//      Synchronize(&UpdateCaption);
//
//   where UpdateCaption could look like:
//
//      void __fastcall TMyThread::UpdateCaption()
//      {
//        Form1->Caption = "Updated in a thread";
//      }

Т.е.- все же все VCL

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

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

@BRcr · 28.08.2012, 20:11

Короче, если суммировать, то Synchronize() требуется только для объектов, которые могут быть заняты в случайное время без ведома программиста - в результате активности операционки по большей части. Вся VCL под это определение, в принципе, подпадает.

@Avazart · 28.08.2012, 23:25

вся VCL под это определение, в принципе, подпадает.

Ну а зачем например синхронизировать Synchronyze() такие объекты как TStringList или IdHTTP ...
Тут нужно смотреть по общей картине...

Новые блоги и статьи Все статьи Все блоги /
Как дизайн сайта влияет на конверсию: 7 решений, которые реально повышают заявки Neotwalker 08.03.2026 Многие до сих пор воспринимают дизайн сайта как “красивую оболочку”. На практике всё иначе: дизайн напрямую влияет на то, оставит человек заявку или уйдёт через несколько секунд. Даже если у вас. . .	Модульная разработка через nuget packages DevAlt 07.03.2026 Сложившийся в . Net-среде способ разработки чаще всего предполагает монорепозиторий в котором находятся все исходники. При создании нового решения, мы просто добавляем нужные проекты и имеем. . .	Модульный подход на примере F# DevAlt 06.03.2026 В блоге дяди Боба наткнулся на такое определение: В этой книге («Подход, основанный на вариантах использования») Ивар утверждает, что архитектура программного обеспечения — это структуры,. . .	Управление камерой с помощью скрипта OrbitControls.js на Three.js: Вращение, зум и панорамирование 8Observer8 05.03.2026 Содержание блога Финальная демка в браузере работает на Desktop и мобильных браузерах. Итоговый код: orbit-controls-threejs-js. zip. Сканируйте QR-код на мобильном. Вращайте камеру одним пальцем,. . .
SDL3 для Web (WebAssembly): Синхронизация спрайтов SDL3 и тел Box2D 8Observer8 04.03.2026 Содержание блога Финальная демка в браузере. Итоговый код: finish-sync-physics-sprites-sdl3-c. zip На первой гифке отладочные линии отключены, а на второй включены:. . .	SDL3 для Web (WebAssembly): Идентификация объектов на Box2D v3 - использование userData и событий коллизий 8Observer8 02.03.2026 Содержание блога Финальная демка в браузере. Итоговый код: finish-collision-events-sdl3-c. zip Сканируйте QR-код на мобильном и вы увидите, что появится джойстик для управления главным героем. . . .	Реалии Hrethgir 01.03.2026 Нет, я не закончил до сих пор симулятор. Эта задача сложнее. Не получилось уйти в плавсостав, но оно и к лучшему, возможно. Точнее получалось - но сварщиком в палубную команду, а это значит, в моём. . .	Ритм жизни kumehtar 27.02.2026 Иногда приходится жить в ритме, где дел становится всё больше, а вовлечения в происходящее — всё меньше. Плотный график не даёт вниманию закрепиться ни на одном событии. Утро начинается с быстрых,. . .

@calculon 14 / 14 / 2 Регистрация: 18.07.2012 Сообщений: 79

	Зависание потоков при обращени к ListBox 27.08.2012, 08:54. Показов 1714. Ответов 13 Метки нет (Все метки) Столкнулся со следующей проблемой. Есть основная форма приложения. Есть рабочие потоки. В качестве логера им передается адрес ListBox'a на основной форме. При входе в поток и выходе из него в лог вносятся соответсвующие записи (при этом разумеется используются критические секции). Так вот если пытаться корректно завершить работу потока передачей ему соответсвующего флага и ждать его через WaitForSingleObject() то программа попросту виснет. Дебаг показал что происходит это это при входе в pListBox->Items->Add(). Если эту строчку убрать все работает как часы. Есть ли соображения по этому поводу? Да, заранее всем спасибо... 0

@Avazart 8488 / 6155 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	28.08.2012, 01:29
	Используй класс TThread Подробней в этой книге http://www.ozon.ru/context/detail/id/5009785/ 0

@ree4 6 / 6 / 0 Регистрация: 11.04.2011 Сообщений: 130
	28.08.2012, 05:12
	из потока нельзя обращаться на прямую к VCL, поэтому и висяки 0

@calculon 14 / 14 / 2 Регистрация: 18.07.2012 Сообщений: 79
	28.08.2012, 05:34 [ТС]
	[QUOTE=Avazart;3395273]Используй класс TThread А чем плох обычный вызов CreateThread? TThread ведь просто обертка... 0

@BRcr 4043 / 2333 / 292 Регистрация: 03.02.2011 Сообщений: 5,066 Записей в блоге: 10
	28.08.2012, 17:31
	Avazart, а не в курсе, почему начиная именно с TWinControl? Что там такого ввели, что возникают конфликты доступа? 0

@Avazart 8488 / 6155 / 615 Регистрация: 10.12.2010 Сообщений: 28,683 Записей в блоге: 30
	28.08.2012, 17:37
	Ну TWinControl этож базовый всех оконных? Или я не прав? Добавлено через 4 минуты Хотя видимо не прав... - TControl 0

@BRcr 4043 / 2333 / 292 Регистрация: 03.02.2011 Сообщений: 5,066 Записей в блоге: 10
	28.08.2012, 18:17
	Насколько можно судить по справочным описаниям, TWinControl вводит свойства и методы для работы именно с визуальными элементами, которые предоставляет операционка. Это его основное отличие от предков. А откуда знаешь, что синхронизация нужна только для потомков TWinControl, а не для всех объектов VCL? 0

@BRcr 4043 / 2333 / 292 Регистрация: 03.02.2011 Сообщений: 5,066 Записей в блоге: 10
	28.08.2012, 18:34
	Да, TControl вводит функционал для работы с некими визуальными компонентами, однако там нет и намека на работу с оконными элементами операционки. Еще вопрос, что Архангельский под этим подразумевает... 0

@volvo Супер-модератор 33398 / 21508 / 8236 Регистрация: 22.10.2011 Сообщений: 36,906 Записей в блоге: 12
	28.08.2012, 18:41
	Синхронизация нужна для non thread-safe объектов. TControl еще является потокобезопасным. И, соответственно, его наследники, если написаны правильно, могут быть потокобезопасны (тогда с ними можно работать без Synchronize). А вот TWinControl уже сам не thread-safe, то есть, все его потомки по определению не могут быть безопасны => только с синхронизацией. 0

@BRcr 4043 / 2333 / 292 Регистрация: 03.02.2011 Сообщений: 5,066 Записей в блоге: 10
	28.08.2012, 20:11
	Короче, если суммировать, то Synchronize() требуется только для объектов, которые могут быть заняты в случайное время без ведома программиста - в результате активности операционки по большей части. Вся VCL под это определение, в принципе, подпадает. 0

Опции темы