Про синхронизацию

← →
Dimka Maslov © (2012-02-03 21:55) [0]

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

← →
antonn © (2012-02-03 22:25) [1]

> Теперь вопрос: чем это грозит?

самыми неожиданными последствиями

← →
DVM © (2012-02-03 22:33) [2]

> Теперь вопрос: чем это грозит?

зависанием как правило

> Все эти дела вытворялись в рамках Synchronize. Но стал
> я замечать жуткий тормоз, аж на несколько порядков

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

← →
DVM © (2012-02-03 22:35) [3]

> берёт и получает данные, провоцирует перерисовку

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

← →
Dimka Maslov © (2012-02-03 22:53) [4]

> зависанием как правило

Вовсе нет. Всё даже шустренько работает.

> ты небось сто тыщ миллионов итераций делаешь и на каждой
> синхронизируешь?

Опять же нет. Расчёт выполняется в рамках написанного самим усером скрипта. Прога - типа отладчик. Синхронизация происходит только при переходе на новую строку.

> надо брать из какого-то хранилища

Данные - это информация о breakpoints, watches, call stack и промежутный результат работы. Они и так находятся в хранилище. Если нет условия останова - просто подсвечивается очередная строка. Если есть - потоку делается суспенд. Если watch изменился - он краснеет, если был вход/выход в подпрограмму это отображается в окне, если был сброс данных в поток вывода - тоже отображается. Другими словами, выполнение таки каждой строки должно отражаться на форме. Так и происходит. Но с синхронизой - гораздо медленнее чем без неё. А синхронизе это и есть критическая секция.

← →
DVM © (2012-02-03 22:56) [5]

> Dimka Maslov © (03.02.12 22:53) [4]

> Вовсе нет. Всё даже шустренько работает.

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

> Опять же нет.

сколько раз в секунду вызывается Synchronize? Не может все тормозить из-за нее при малом количестве вызовов.

> А синхронизе это и есть критическая секция.

нет

← →
DVM © (2012-02-03 22:59) [6]

> Другими словами, выполнение таки каждой строки должно отражаться
> на форме. Так и происходит. Но с синхронизой - гораздо медленнее
> чем без неё

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

← →
Dimka Maslov © (2012-02-03 23:04) [7]

>
> попробуй сделать ресайз форме, может повиснуть

Попробовал. Не виснет. Но глючит при перерисовке.

> сколько раз в секунду вызывается Synchronize?

Каждый раз при начале работы с новой строкой. Реальную скорость я не замерял.

← →
Dimka Maslov © (2012-02-03 23:06) [8]

> нет

Вроде как в коде метода она явно присутствует.

> переделать на сообщениях

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

← →
DVM © (2012-02-03 23:13) [9]

> Dimka Maslov © (03.02.12 23:06) [8]

> но хочется понять, чем вообще грозит (может грозить) отсутствие
> синхронизации, кроме глюков при перерисовке в момент ресайза?
>

Да чем угодно. Представь себе, что во время работы какой то функции в одном потоке изменились значения с которыми она работает из другого потока. Например уменьшилась длина строки. Совершенно непредсказуемые последствия.

← →
DVM © (2012-02-03 23:18) [10]

> Вроде как в коде метода она явно присутствует.

Щас (XE) там присутствует TMonitor

← →
Dimka Maslov © (2012-02-03 23:21) [11]

> DVM © (03.02.12 23:13) [9]

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

← →
Dimka Maslov © (2012-02-03 23:23) [12]

> Щас (XE) там присутствует TMonitor

В 2009 там совокупность критической секции и ожидания события.

← →
Dimka Maslov © (2012-02-03 23:29) [13]

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

← →
DVM © (2012-02-03 23:30) [14]

> Dimka Maslov © (03.02.12 23:21) [11]

> Вот это как раз изолировано. Единственная взаимосвязь между
> основным потоком и расчётным - как написано выше.

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

← →
DVM © (2012-02-03 23:34) [15]

> Получается, что синхронизация нужна только для прорисовки,
> а это процесс куда как более медленный, нежели сам расчёт.
>

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

> Короче, есть в программе переменные, операции с которыми
> не атомарны, которые в один и тот же момент времени один
> поток может менять

Чтобы одновременно - нет. Основной поток подгатавливает "хранилище", расчётный его использует. И ещё перерисовывает. Получается, что если нет перерисовки, синхронизация не нужна. Если есть - нужна. Или всегда нужна, на всякий пожарный случай.

> и по таймеру читал эти свойства формой

В этом и проблема, что интерфейс должен обновляться не по таймеру а в строго определённое время.

Склоняюсь всё-таки к избавлению от средств синхронизации с посылкой SendMessage на перерисовку.

> Dimka Maslov © (03.02.12 23:36) [16]

> Чтобы одновременно - нет.

а как же

> И ещё перерисовывает.

Значит есть такие общие переменные. Что-то же отрисовывается?

> Dimka Maslov © (04.02.12 10:31) [19]

> Глюки проявляются именно при перерисовке. Больше нигде.
> Туда и буду копать.

Как бы у тебя утечек объектов GDI при этом не возникло.

> Как бы у тебя утечек объектов GDI при этом не возникло.

Я не пользуюсь классом TCanvas, создаю все объекты в начале работы, уничтожаю в конце. Их не так много.

Про синхронизацию Найти похожие ветки