Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Потоки. Нужна ли синхронизация? [D6, XP]

Страницы: < 1 2 3 4 5 6 7
vint45 © (2008-06-17 12:42:00)
Здраствуйте. Есть приложение, в котором выполняются несколько потоков. Каждый поток имеет свой локальный набор переменных. Требуется периодически считывать из главного потока значения некоторых локальных переменных этих потоков (сбор статданных, для последующего отображения статистики на экране).
Вопрос. Надо ли помещать в критическую секцию процесс чтения локальных переменных главным потоком из остальных потоков?
ps прочитал пару статей по потокам, но там в основном рассматриваются варианты, когда потоки пытаются изменять, а не читать общие переменные.

Leonid Troyanovsky (2008-06-17 18:24:00) [121]

> Тын-Дын © (17.06.08 17:48) [15]

> Резюме - только критичские секции (либо Synchronize).

Synchronize работает с той же стороны, что и SendMessage.
Впрочем, это не препятствие, см. также [16].

Главное, чтобы синхронизация имела место, что, собс-но,
и беспокоило вопрошающего, IMHO.

--
Regards, LVT.

Leonid Troyanovsky (2008-06-17 18:18:00) [122]

> Тын-Дын © (17.06.08 17:48) [15]

> > организовать из потоков SendMessage в главный поток с
> уведомлением
> > об изменении той или иной переменной в данном потоке

> Инициатор - основной поток, а не дополнительные. По условию.

Если все изменения становятся доступны первичному потоку,
то какая нах разница - он волен в проявлении своей инициативы,
работая со своей копией данных.

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

--
Regards, LVT.

Leonid Troyanovsky (2008-06-17 18:08:00) [123]

> MsGuns © (17.06.08 15:57) [14]

> при следующем "опросе"). Т.к. поток не влияет на канву,
> его действия в общем случае можно не синхронизировать, ибо
> он пишет только в "свои" участки памяти, не пересекающиеся
> ни с кэшами других потоков, ни с памятью гл.потока, занятой

Не только ж канва нуждается в синхронизации.
А насчет пересечений в вопросе прямо cказано

> считывать из главного потока значения некоторых локальных переменных
> этих потоков

Отсутствие синхронизации доступа здесь вовсе недопустимо,
бо считанное будет, в общем случае, абсурдом.

Асинхронные сообщения от вторичных потоков тоже неочень уместны,
т.к. первичный поток, видимо, рассчитывает получить согласованные
данные, скажем, по состоянию на момент опроса.

--
Regards, LVT.

Тын-Дын (2008-06-17 17:48:00) [124]

> Palladin © (17.06.08 13:57) [13]
>
> > я вас не совсем понял.. т.е. если переменные изменяются
>
> > редко, то синхронизацию можно не проводить?
>
> нет, от этого зависит путь решения
>
> 1. если переменные изменяются редко, то имеет смысл просто
> организовать из потоков SendMessage в главный поток с уведомлением
> об изменении той или иной переменной в данном потоке

Это подход не с той стороны.
Инициатор - основной поток, а не дополнительные. По условию.

> 2.а либо реализовать на основе таймеров забор значений,
> но он мне не нравится

Нет такого подхода при работе с потокми.

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

См. пред. пункт.

Резюме - только критичские секции (либо Synchronize).

MsGuns (2008-06-17 15:57:00) [125]
>Leonid Troyanovsky © (17.06.08 13:18) [12]
>> Потоки пишут в кэши через Synchronize (хотя, возможно, это
>> и не обязательно)
>С чего бы это "возможно"?

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

Palladin (2008-06-17 13:57:00) [126]

> я вас не совсем понял.. т.е. если переменные изменяются
> редко, то синхронизацию можно не проводить?

нет, от этого зависит путь решения

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

vint45 (2008-06-17 13:18:00) [127]

> Leonid Troyanovsky © (17.06.08 13:16) [9]

Спасибо

Leonid Troyanovsky (2008-06-17 13:18:00) [128]

> MsGuns © (17.06.08 12:51) [4]

> Потоки пишут в кэши через Synchronize (хотя, возможно, это
> и не обязательно)

С чего бы это "возможно"?

--
Regards, LVT.

Поросенок Винни-Пух (2008-06-17 13:17:00) [129]
считывать из главного потока значения некоторых локальных переменных этих потоков (сбор статданных, для последующего отображения статистики на экране).

Посылать сообщение в главный поток со значениями когда эти значения меняются.
В главном ничего не читать

Leonid Troyanovsky (2008-06-17 13:16:00) [130]

> vint45 (17.06.08 12:42)

> Вопрос. Надо ли помещать в критическую секцию процесс чтения
> локальных переменных главным потоком из остальных потоков?

Любое обращение к перменной из любого потока должно идти через КС.
Либо через InterLocked*. Либо из вторичных потоков через Synchronize.

--
Regards, LVT.

vint45 (2008-06-17 13:14:00) [131]

> Palladin © (17.06.08 12:55) [6]
> фу блин... задачу воспринял с точностью до наоборот...
>
> решение зависит от частоты изменения этих локальных переменных
> и от того насколько часто необходимо считывать статданные.
> ..

я вас не совсем понял.. т.е. если переменные изменяются редко, то синхронизацию можно не проводить?

vint45 (2008-06-17 13:02:00) [132]

> Palladin ©
задачей главного потока является отображение в форме значений локальных переменных изменяемых в остальных потоках

> MsGuns ©
Потоки пишут в кэши через Synchronize (хотя, возможно, это и не обязательно)

вот меня как раз этот вопрос и интересует

Palladin (2008-06-17 12:55:00) [133]
фу блин... задачу воспринял с точностью до наоборот...

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

Поросенок Винни-Пух (2008-06-17 12:52:00) [134]
меняют сами потоки (за исключением главного), производя некоторую деятельность

И что?
Передай им все значения при создании потоков.
И не читай то что не меняется.

Palladin (2008-06-17 12:51:00) [135]

> когда потоки пытаются изменять, а не читать общие переменные

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

MsGuns (2008-06-17 12:51:00) [136]
В данном случае надо в теле модуля, доступного всем юнитам-потокам, зарезервировать список с адресами объектов-кэшей для каждого потока.
Каждый поток при запуске добавляет в этот список указатель на собственный объект-кэш (в простейшем случае record) и в процессе выполнения пишет в него свои значения, не "мешая" другим. Гл.форма (или что там выполняется в основном потоке) с определенной периодичностью (TTimer) анализирует содержимое кэшей и отображает их в чем-то визуальном.
Потоки пишут в кэши через Synchronize (хотя, возможно, это и не обязательно)

vint45 (2008-06-17 12:47:00) [137]
меняют сами потоки (за исключением главного), производя некоторую деятельность

Поросенок Винни-Пух (2008-06-17 12:43:00) [138]
а нафик их периодически читать, если их значения никто не меняет?

Страницы: < 1 2 3 4 5 6 7

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »