Поток подвешивает форму

@SatanaXIII · Регистрация: 01.11.2011

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

Господа, что-то я явно делаю не правильно, а что никак не пойму.
В основной форме, по кнопке создаю поток

C++
1
2
void __fastcall TFormPlan::Button1Click(TObject *Sender)
{Thr1 = new ThreadMove(false);}

в котором, через Synchronize запускаю длинный цикл. В цикле ставлю Sleep(1). При нажатии на кнопку форма передает управление потоку, и пока тот не завершится, обратно управление не принимает. Хотя по логике должна в момент Sleep-а. Или как?

Добавлено через 34 минуты
И если я одновременно создам два таких потока, то они должны выполняться параллельно. В этом их и суть. А не ждать пока завершится первый.

@SatanaXIII · 03.07.2012, 16:58 **[ТС]**

Avazart, может быть действительно у меня где-то корявый алгоритм, но я вон приводил в примере, что при выполнении первого потока при движении лейбла вправо, если запустить второй поток, то второй лейбл уползет на лишние 200 пикселей далее. А если не запускать первый поток, то не уползает. Зависимость на лицо.
И это только один из примеров. Я замечал и другие странности, которые конечно очень легко объяснить просто отсутствием синхронизации, но только вот непонятно, что с этим делать.

@Avazart · 03.07.2012, 18:45

Ну так должно быть.Непойму что не устраивает.
Каждый поток сдвигает лэбел на 200 вот тебе 200+200

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

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
__fastcall TMyThread::TMyThread(bool CreateSuspended,int i)
    : TThread(CreateSuspended)
{
this->i= i;
FreeOnTerminate = true;
}
//---------------------------------------------------------------------------
void __fastcall TMyThread::Execute()
{
for(int i=0; i<200; i++)
  {
  Synchronize(&Move);
  Sleep(10);
  }
}
//---------------------------------------------------------------------------
void __fastcall TMyThread::Move()
{
if(i==1) Form1->Label1->Left++;
if(i==2) Form1->Label1->Top++;
}
//---------------------------------------------------------------------------
//---------------------------------------------------------------------------
void __fastcall TForm1::Button1Click(TObject *Sender)
{
TMyThread *Thread1 = new TMyThread(false,1);
TMyThread *Thread2 = new TMyThread(false,2);
}
//---------------------------------------------------------------------------

Работает нормально без подвисаний.
Лэйбел плавно двигается по диагонали вниз-вправо.

@SatanaXIII · 06.07.2012, 09:03 **[ТС]**

Только у меня там два разных лейбла двигаются:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
if(i==1)
for(int i=0;i<200;i++)
  {
  Form3->Label1->Left += 1;
  Form3->Update();
  Sleep(10);
  }
 
if(i==2)
for(int i=0;i<200;i++)
  {
  Form3->Label2->Left += 1;
  Form3->Update();
  Sleep(10);
  }

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

Каждый поток сдвигает лэбел на 200 вот тебе 200+200

Первый поток сдвигает Label1, а второй соответственно Label2. И у второго вот эти вот 200+200 быть не должны. А есть.

@Avazart · 06.07.2012, 20:52

Нормально работает...

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
//---------------------------------------------------------------------------
__fastcall MyThread::MyThread(bool CreateSuspended,int N)
    : TThread(CreateSuspended)
{
this->N= N;
FreeOnTerminate = true;
}
//---------------------------------------------------------------------------
void __fastcall MyThread::Execute()
{
if(N==1)
for(int i=0;i<200;i++)
  {
   Synchronize(&Move1);
   Sleep(10);
  }
 
if(N==2)
for(int i=0;i<200;i++)
  {
   Synchronize(&Move2);
   Sleep(10);
  }
}
//---------------------------------------------------------------------------
void __fastcall MyThread::Move1()
{
 Form1->Label1->Left ++;
}
//---------------------------------------------------------------------------
void __fastcall MyThread::Move2()
{
 Form1->Label2->Left ++;
}
//---------------------------------------------------------------------------

@SatanaXIII · 10.07.2012, 13:32 **[ТС]**

Уважаемый Avazart... не знаю даже с чего начать. В общем из-за тех глюков, которые я у себя наблюдал, мне показалось, что наиболее правильным решением будет переписать все в один поток. Так как один поток обращается к одной же форме и делить ее ни с кем не надо. Но в результате, из-за огромного количества всевозможных проверок и действий, поток так разросся, что оптимизировать его уже не представляется возможным. Как следствие жутчайшие тормоза.

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

Имеет ли мне смысл переписывать свою программу обратно под многопоточность (именно как вы предложили) или я получу тоже самое? Или хз?

@BRcr · 10.07.2012, 15:08

Да какая разница, сколько потоков будут эти две метки двигать? Хоть десятью можно, так-то.

Чтоб много не менять, сделай так, чтобы за одну итерацию цикла потока обе метки сдвигались на единичку. Собственно, и все.

@Avazart · 10.07.2012, 17:00

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

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

Ну это глупо Я говорю- не правильный алгоритм, не стоит сувать в синхроназ все папала, а вы все равно пытаетесь его заставить работать.

@SatanaXIII · 11.07.2012, 12:15 **[ТС]**

Да не. Там не две метки. )) Это просто пример был. Но как выяснилось даже в нем я накосячил. И всего лишь надо было разнести по функциям действия с разными объектами (хотя я до сих пор не понимаю почему это сработало). В моей программе присутствуют такие тяжеловесные конструкции как перебор всех элементов формы, парсеры их имен и запихивание/считывание всего этого дела в структуры. Да и еще парочка потоков рядом постоянно пытаются на себя переманить ресурсы. Повыкидывал откуда смог Form->Update, - стало получше, объекты перемещаются не с такими тормозами, но зато стали самопроизвольно телепортироваться.

Вот я и думаю, мож если б переписать как я хотел изначально, но с учетом вашего варианта исполнения, то мож заработало б как планировалось.

Добавлено через 39 секунд
Avazart, так, ладно. А как бы вы сделали?

Добавлено через 19 часов 13 минут

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

не стоит сувать в синхроназ все папала

Суть моего последнего вопроса - как лучше/правильнее (быстрее чтоб работало) сделать - разбить тело потока на множество функций и засунуть их в каждую в свой метод синхронизации, или так же побить поток на отдельные функции и вынести из них все, что можно в сам метод Execute, оставив под синхронизацией только то, что ссылается на какие-либо внешние данные относительно потока?

@BRcr · 11.07.2012, 16:24

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

побить поток на отдельные функции и вынести из них все, что можно в сам метод Execute, оставив под синхронизацией только то, что ссылается на какие-либо внешние данные относительно потока

В точку.

@SatanaXIII · 12.07.2012, 10:49 **[ТС]**

Спасибо, добрый человек.

Новые блоги и статьи Все статьи Все блоги /
сукцессия 14. Обновленная схема модели anaschu 28.06.2026 ГЛОБАЛЬНАЯ ОПИСАТЕЛЬНАЯ СПЕЦИФИКАЦИЯ ЭКОСИСТЕМНОЙ МОДЕЛИ «SOIL CHEMISTRY & MYCORRHIZA 2. 0» https:/ / ibb. co/ NnkGpfMd Представленная интегрированная схема описывает непрерывную нелинейную. . .	сукцессия 13. Питон модель трехзонного мицелия, пока что в основном арбускулярного anaschu 28.06.2026 ## Разработка агентной модели микоризной сукцессии: от выявления артефактов к созданию комплексной системы ### Аннотация Представлено исследование по разработке агентной модели микоризной. . .	сукцессия 12. краткий список проверок модели перед запуском. anaschu 27.06.2026 Скрытые отказы в моделях систем динамики (SD-models) экологических систем: два случая из практики Контекст Разбирался прототип модели систем динамики (SD-модели) микоризной сукцессии: пять. . .	Сукцессия 11. Проверка орудий перед войной: разработка через тестирование anaschu 27.06.2026 Как не дать модели соврать самой себе: проверки для симуляции микоризной сукцессии Введение Когда вы строите математическую модель живой системы — грибов, растений, почвы — главная опасность. . .
10 сукцессия. Питон код войны грибов и растений anaschu 27.06.2026 import numpy as np class PlantAgent: def __init__(self, name, strategy, initial_biomass): self. name = name self. strategy = strategy # "greedy" (широколиственные) или. . .	сукцессия 9. Математика подлости: как растения предали грибных друзей anaschu 27.06.2026 Статья 2. Глобальная фосфорная война: эволюционно-экономические механизмы распределения биомов Земли Введение: Экологический рынок как игра с нулевой суммой Традиционная экология долгое время. . .	сукцессия 8. Как я спорил с ИИ, которые - агенты растений и ненавистники грибов! anaschu 27.06.2026 Статья 1. Хроники грибного восстания: как Сократов диалог разрушил академические догмы ИИ Введение: Синдром «цифрового учебника» Современные большие языковые модели (LLM) обладают колоссальным. . .	Главный вопрос моделирования сукцессии anaschu 27.06.2026 главный вопрос. Если эктомикориза лучше добывает недоступный фосфор. И ее масса максимальна из всех. А широколиственный лес тоже имеет самую крутую биомассу. То почему не возникло их симбиоза? Это. . .

@SatanaXIII Почетный модератор 5851 / 2862 / 392 Регистрация: 01.11.2011 Сообщений: 6,906
	03.07.2012, 16:58 [ТС]
	Avazart, может быть действительно у меня где-то корявый алгоритм, но я вон приводил в примере, что при выполнении первого потока при движении лейбла вправо, если запустить второй поток, то второй лейбл уползет на лишние 200 пикселей далее. А если не запускать первый поток, то не уползает. Зависимость на лицо. И это только один из примеров. Я замечал и другие странности, которые конечно очень легко объяснить просто отсутствием синхронизации, но только вот непонятно, что с этим делать. 0

@SatanaXIII Почетный модератор 5851 / 2862 / 392 Регистрация: 01.11.2011 Сообщений: 6,906
	10.07.2012, 13:32 [ТС]
	Уважаемый Avazart... не знаю даже с чего начать. В общем из-за тех глюков, которые я у себя наблюдал, мне показалось, что наиболее правильным решением будет переписать все в один поток. Так как один поток обращается к одной же форме и делить ее ни с кем не надо. Но в результате, из-за огромного количества всевозможных проверок и действий, поток так разросся, что оптимизировать его уже не представляется возможным. Как следствие жутчайшие тормоза. Вся разница в приведенном вами метода и тем, что пытался изобразить я, лишь в том, что в методе Execute потока у меня выполняется одна синхронизированная функция, содержащая проверки условий и прочее, а у вас сама проверка происходит непосредственно в теле метода Execute, а действия с формами в отдельных (нескольких!) функциях. Имеет ли мне смысл переписывать свою программу обратно под многопоточность (именно как вы предложили) или я получу тоже самое? Или хз? 0

@BRcr 4043 / 2333 / 292 Регистрация: 03.02.2011 Сообщений: 5,066 Записей в блоге: 10
	10.07.2012, 15:08
	Да какая разница, сколько потоков будут эти две метки двигать? Хоть десятью можно, так-то. Чтоб много не менять, сделай так, чтобы за одну итерацию цикла потока обе метки сдвигались на единичку. Собственно, и все. 0

@SatanaXIII Почетный модератор 5851 / 2862 / 392 Регистрация: 01.11.2011 Сообщений: 6,906
	12.07.2012, 10:49 [ТС]
	Спасибо, добрый человек. 0