Потоки. Нужна ли синхронизация?

← →
vint45 (2008-06-17 12:42) [0]

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

← →
Поросенок Винни-Пух © (2008-06-17 12:43) [1]

а нафик их периодически читать, если их значения никто не меняет?

← →
vint45 (2008-06-17 12:47) [2]

меняют сами потоки (за исключением главного), производя некоторую деятельность

← →
Palladin © (2008-06-17 12:51) [3]

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

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

← →
MsGuns © (2008-06-17 12:51) [4]

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

← →
Поросенок Винни-Пух © (2008-06-17 12:52) [5]

меняют сами потоки (за исключением главного), производя некоторую деятельность

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

← →
Palladin © (2008-06-17 12:55) [6]

фу блин... задачу воспринял с точностью до наоборот...

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

← →
vint45 (2008-06-17 13:02) [7]

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

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

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

← →
vint45 (2008-06-17 13:14) [8]

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

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

← →
Leonid Troyanovsky © (2008-06-17 13:16) [9]

> vint45 (17.06.08 12:42)

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

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

--
Regards, LVT.

← →
Поросенок Винни-Пух © (2008-06-17 13:17) [10]

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

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

← →
vint45 (2008-06-17 13:18) [11]

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

Спасибо

← →
Leonid Troyanovsky © (2008-06-17 13:18) [12]

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

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

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

--
Regards, LVT.

← →
Palladin © (2008-06-17 13:57) [13]

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

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

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

← →
MsGuns © (2008-06-17 15:57) [14]

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

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

← →
Тын-Дын © (2008-06-17 17:48) [15]

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

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

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

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

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

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

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

← →
Leonid Troyanovsky © (2008-06-17 18:08) [16]

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

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

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

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

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

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

--
Regards, LVT.

← →
Leonid Troyanovsky © (2008-06-17 18:18) [17]

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

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

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

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

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

--
Regards, LVT.

← →
Leonid Troyanovsky © (2008-06-17 18:24) [18]

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

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

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

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

--
Regards, LVT.

← →
Palladin © (2008-06-17 18:44) [19]

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

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

← →
Palladin © (2008-06-17 18:50) [20]

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

да ты что... обоснуй

← →
Тын-Дын © (2008-06-17 19:11) [21]

Да нет. Это уж ты обоснуй, раз уж утверждаешь, что таймерами можно синхронизировать доступ меж потоками. Можешь даже сослаться на что-нибудь.

← →
Palladin © (2008-06-17 19:52) [22]

> Тын-Дын © (17.06.08 19:11) [21]

:) смешной... таймеры частный случай 2.б., только вместо отдельного монитора потока на форму кидаются таймеры, или один таймер, но с опросом всех потоков.

интересно, где же ты решил что с использованием таймеров КС не понадобятся...

← →
Тын-Дын © (2008-06-17 22:09) [23]

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

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

> :) смешной... таймеры частный случай 2.б.,

И никоим образом к синхронизации не относятся.
И то, и другое без средств синхронизации не сделаешь.
Таймеры тут ни при чем. Нет такого средства/метода синхронизации, как таймер.

Плодить дополнительный поток для сбора данных, необходимых основному потоку - бред.

Правильное решение - использовать критические секции для чтения данных из доп. потоков.

> Leonid Troyanovsky © (17.06.08 18:18) [17]
>Если все
> изменения становятся доступны первичному потоку,то какая
> нах разница - он волен в проявлении своей инициативы,работая
> со своей копией данных.Синхронизацию через SendMessage окну
> первичного потока пользовалираннии версии дельфи, и особого
> криминала здесь замечено не было, за исключением некоторых
> вырожденных случаев.

А разница в том, что основному потоку в определенный момент времени нужны данные, а не произвольно поступающие от потоков посредством SendMessage.

← →
Тын-Дын © (2008-06-17 22:10) [24]

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

← →
ANB (2008-06-17 22:21) [25]

> А разница в том, что основному потоку в определенный момент
> времени нужны данные, а не произвольно поступающие от потоков
> посредством SendMessage.

Обработчик их складет в буфер. Когда основному потоку встеблится их пользовать - оттуда и достанет.

> Вообще не могу понять, причем здесь таймеры? На кой они
> ляд?

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

ЗЫ. Если потоки сами по себе ничего не считают, а большую часть времени ждут отклика от внешних источников - нормальное решение. Однако, если потоки заняты расчетами на своем проце, то синхронизация убьет практически все преимущество от распараллеливания.

← →
Тын-Дын © (2008-06-17 22:26) [26]

> Обработчик их складет в буфер. Когда основному потоку встеблится
> их пользовать - оттуда и достанет.

И? Чем это отличается от чтения из основного потока?

> Если основной поток мониторит ход работы доп.потоков то
> таймер на опросе - самое простое решение.

В условии нет никаких таймеров. Предлагается какое-то решение с таймерами. Для чего?

> ЗЫ. Если потоки сами по себе ничего не считают, а большую
> часть времени ждут отклика от внешних источников - нормальное
> решение. Однако, если потоки заняты расчетами на своем проце,
> то синхронизация убьет практически все преимущество от
> распараллеливания.

Неважно, КАК работают потоки.
Есть некий факт - нужно в неопределённый момент времени получить от каждого потока данные.

Никаких проблем не возникнет в случае синхронизации. Никакой потери преимуществ. Да и странно было бы, если бы было иначе.

← →
oxffff © (2008-06-17 22:35) [27]

> Leonid Troyanovsky © (17.06.08 13:16) [9]
>
> > vint45 (17.06.08 12:42)
>
> > Вопрос. Надо ли помещать в критическую секцию процесс
> чтения
> > локальных переменных главным потоком из остальных потоков?
>
>
> Любое обращение к перменной из любого потока должно идти
> через КС.
> Либо через InterLocked*. Либо из вторичных потоков через
> Synchronize.
>
> --
> Regards, LVT.

Ссылочку на должествование не приведете?
Поток чтения может обращаться к shared данным напрямую.

Для многоядерного(односокетного) компьютера нет необходимости использования InterLocked* функций в потоках записи.

Для многосокетного компьютера можно натолкнуться на
Synchronization and Multiprocessor Issues в случае, если есть зависимое чтение. То есть на основе анализа состояния одних данных извлекать другие. В MSDN есть пример. Тогда действительно любые инструкции процессора с Lock префиксом (InterLocked* WIN 32 API).
Если нет зависимого чтения, то InterLocked* не нужны.

Это все естественно для случая когда вы читаете сырые данные без привязки к какому либо моменту.

← →
ANB (2008-06-17 22:38) [28]

>
> И? Чем это отличается от чтения из основного потока?

Тем что чтение мона проводить незащищенно. А запись из доп.потоков синхронизнет ОС.

> В условии нет никаких таймеров. Предлагается какое-то решение
> с таймерами. Для чего?

Для удобства. А если не надо мониторить работу потоков - зачем вообще куда то что то из потоков писать ?

> Никаких проблем не возникнет в случае синхронизации. Никакой
> потери преимуществ. Да и странно было бы, если бы было иначе.
>

Проблем - не возникнет. Просто если потоки только считают что то толстое на своем компе, то скорость многопоточного расчета будет как минимум не быстрее, чем в одном потоке. Это и будет потерей преимущества.

← →
Тын-Дын © (2008-06-17 22:45) [29]

> Тем что чтение мона проводить незащищенно.

Нельзя.

> > В условии нет никаких таймеров. Предлагается какое-то
> решение > с таймерами. Для чего?Для удобства. А если не
> надо мониторить работу потоков - зачем вообще куда то что
> то из потоков писать ?

В чём удобство - поясни?

> Проблем - не возникнет. Просто если потоки только считают
> что то толстое на своем компе, то скорость многопоточного
> расчета будет как минимум не быстрее, чем в одном потоке.
> Это и будет потерей преимущества.

о чём разговор? Про доп. потоки что-то известно было?
Весь вопрос - надо получить данные и нужно ли синхронизировать.

Ответ - ДА. Как? Критическими секциями.

← →
Тын-Дын © (2008-06-17 22:47) [30]

> Поток чтения может обращаться к shared данным напрямую.

Не может.

← →
oxffff © (2008-06-17 22:49) [31]

> Тын-Дын © (17.06.08 22:47) [30]
>
> > Поток чтения может обращаться к shared данным напрямую.
>
>
>
> Не может.

А почему ты так думаешь?
Внимательно ли был прочитан мой пост?

Это все естественно для случая когда вы читаете сырые данные без привязки к какому либо моменту.
Может. :)

← →
Тын-Дын © (2008-06-17 23:00) [32]

> Это все естественно для случая когда вы читаете сырые данные
> без привязки к какому либо моменту.

Тогда давай подробнее про сырые данные.
Что это такое?

← →
oxffff © (2008-06-17 23:08) [33]

> Тын-Дын © (17.06.08 23:00) [32]

Если один поток пишет данные(вычисляет) , а второй только читает(отображает на экране).
Зачем делать синхронизацию, если данные актуальные на момент чтения.
Если нет требований к привязки к моменту(очередности), то данные которые были между двумя моментами чтения можно пропустить.
Это случай когда данные пишутся не в очередь, а просто расположены в Shared переменных. И если они отображаются на экране, то поток чтения может просто считывать их 25 раз в секунду, более не нужно.

← →
oxffff © (2008-06-17 23:11) [34]

> Тын-Дын © (17.06.08 23:00) [32]
>
> > Это все естественно для случая когда вы читаете сырые
> данные
> > без привязки к какому либо моменту.
>
>
> Тогда давай подробнее про сырые данные.
> Что это такое?

Читал вопрос внимательно?

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

← →
ANB (2008-06-17 23:25) [35]

> > Тем что чтение мона проводить незащищенно.
>
>
> Нельзя.

Почему ? Пишет в этот буфер главный поток (обработчиком сообщения), читает он же.

> В чём удобство - поясни?

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

При этом главная форма висеть не будет.

> oxffff © (17.06.08 23:08) [33]

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

← →
MsGuns © (2008-06-17 23:33) [36]

Чем дальше в лес, тем толще партизаны. Синхронизация не является необходимой, например, в таком случае.
Приложение предусматривает запуск длительного многошагового расчета чего-нибудь. При этом сам расчет выполняется в N шагов и может быть завершен одним из след. способов:
- нормальное завершение
- ошибка на сервере
- ошибка при обработке данных на клиенте (например, несоответствие данных или по памяти)
- прервано пользователем.

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

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

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

← →
Тын-Дын © (2008-06-17 23:48) [37]

> oxffff © (17.06.08 23:08) [33]
> > Тын-Дын © (17.06.08 23:00) [32] Если один поток пишет
> данные(вычисляет) , а второй только читает(отображает на
> экране).Зачем делать синхронизацию, если данные актуальные
> на момент чтения.

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

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

Ну и? Как это притиворечит пердыдущему абзацу?

> ANB (17.06.08 23:25) [35]

> Почему ? Пишет в этот буфер главный поток (обработчиком
> сообщения), читает он же.

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

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

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

> MsGuns © (17.06.08 23:33) [36]

> Чтобы код соответствовал "высоким технологиям" и вумным
> книжкам ?

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

> анализируется соотв. поле рекорда - статусное.

Ты забыл сказать про тип этого поля.
В случае Boolean запись проходит атомарно.
Если у тебя в поле целое число или строка, то глюки неизбежны.
Хотя при Integer современные процессоры вроде бы теперь тоже атомарно операции выполняют(присвоение).

← →
ANB (2008-06-17 23:50) [38]

> В зависмости от его состояния (а его изменяет сам поток
> без всякой синхронизации)

Прямой записью в память, которую периодически читает главный поток ?

Чет я отстал от жизни.

← →
ANB (2008-06-17 23:54) [39]

> На момент, когда основному потоку могут понадобиться данные
> из этого буфера, в доп. потоке они уже могут измениться.
>
> Т.е. для получения согласованных данных ВСЕ доп. потоки
> должны записать свои данные в буфер, не производя больше
> вычмслений, и сразу же основной поток должен их прочитать.
>
>
>
> > Писать меньше - в обработчик таймера засунул визуализацию
>
> > и всех делов.При этом главная форма висеть не будет.
>
>
> Ну никак по таймеру невозможно данные синхронизировать.
> Основной поток должен их получить в произвольный момент
> времени. Например, при нажатии пользователем на кнопку.

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

Кнопочка и таймер - не противоречат друг другу.

А согласованность данных при многопоточных вычислениях - тады уж лучше и не устраивать многопоточность.

← →
Тын-Дын © (2008-06-17 23:56) [40]

> Поток изменил данные - послал сообщение, данные в буфере
> поменялись.

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

← →
Тын-Дын © (2008-06-17 23:57) [41]

> ANB (17.06.08 22:21) [25]
>...
>то синхронизация убьет практически все преимущество
> от распараллеливания.

Это как раз та ситуация.

← →
ANB (2008-06-18 00:12) [42]

> то основной поток совсем захлебнётся их обработкой

Дык не надо спамить. Если состояние потоков нужно редко, так и скидывать в основной поток их надо пореже.

← →
MsGuns © (2008-06-18 00:23) [43]

>Ну можно и глючно писать, без чтения умных книжек и тривиальной логики. >Оно стоит того?

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

>Ты забыл сказать про тип этого поля.
>В случае Boolean запись проходит атомарно.
>Если у тебя в поле целое число или строка, то глюки неизбежны.
>Хотя при Integer современные процессоры вроде бы теперь тоже атомарно >операции выполняют(присвоение).

тип - перечислимое (т.е. бул), но вот чего не могу понять А КАКАЯ РАЗНИЦА ? Ну прочитает гл.поток не полностью записанную строку (в случае стринга хотя бы), и что ? В чем глюк ? В том, что на секунду в соотв. строке сетки процессов отобразится что-то несуразное ? Где здесь криминал и чем этот "жестокий глюк" чреват для пользователя, который, скорее всего, в этот момент смотрит в чашку с кофе или считает ворон за окном ?

Вот не надо с умным лицом советовать делать табуретки натфилем и лобзиком

← →
Тын-Дын © (2008-06-18 00:50) [44]

> Дык не надо спамить. Если состояние потоков нужно редко,
> так и скидывать в основной поток их надо пореже.

Пореже - это как?
В некоторый момент времени основному потоку понадобились данные. Как он узнает, актуальны ли данные, полученные от потоков?

> MsGuns © (18.06.08 00:23) [43]

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

Вот потому, что -
> тип - перечислимое (т.е. бул),

Не бул, а байт. (Кстати, размер BOOL - 4 байта, Boolean - 1 байт).

Работа с байтом - всегда атомарная операция, потому до сих пор и не возникало проблем. Замени на Integer - получишь проблемы очень скоро.

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

Ну если тебе в данный момент всё равно, что получаемые данные чушь, то кто ССЗБ?

> Вот не надо с умным лицом советовать делать табуретки натфилем
> и лобзиком

Исходя из высказывания в пред. абзаце я бы посоветовал, как многие тут, метлу в руки, но не буду. Сам бы убил за такие советы (советы другим, не себе. Мне-то всё равно).
Знание - сила. Лучше иногда теорию читать и на практике использовать.
"Метод тыка" - это хорошо, конечно, но иногда может привести к непредсказуемым последствиям.

← →
Palladin © (2008-06-18 09:34) [45]

> Тын-Дын © (17.06.08 22:09) [23]

Очень увлекательные комметарии, вот только не в ту степь и не в тему. Вот ты талдонишь о том что единственное правильное решение использовать критические секции. Замечательно. Заметь, я нигде этого не опровергал, лишь заметил, что в можно отработать и через SendMessage, ничего в этом криминального нет. Ну это ладно. Начнем издалека. Ответь на вопрос: какова цель использования критических секций?

← →
MsGuns © (2008-06-18 09:45) [46]

>Тын-Дын © (18.06.08 00:50) [44]

Ты случаем не академик ? А то стиль вещания очень академический: мол делай как я сказал - иначе могила.

← →
ANB (2008-06-18 10:19) [47]

> лишь заметил, что в можно отработать и через SendMessage

Все верно. Это всего лишь другой подход к синхронизации. Позволяет обойтись без критических секций (во всяком случае - своих).
Это я для Тын-Дын ©.

А вот если синхронизация начинает тормозить работу, вот тогда надо использовать что то другое. Например - PostMessage или вот надо попробовать методу МсГанса.

> MsGuns © (18.06.08 09:45) [46]

Милин, а почему когда я попробовал так делать, у меня AV лезли ?

← →
Тын-Дын © (2008-06-18 12:41) [48]

> Palladin © (18.06.08 09:34) [45]
>
> > Тын-Дын © (17.06.08 22:09) [23]
>
> Очень увлекательные комметарии, вот только не в ту степь
> и не в тему. Вот ты талдонишь о том что единственное правильное
> решение использовать критические секции. Замечательно. Заметь,
> я нигде этого не опровергал, лишь заметил, что в можно
> отработать и через SendMessage, ничего в этом криминального
> нет. Ну это ладно. Начнем издалека. Ответь на вопрос: какова
> цель использования критических секций?

Очень снобский пост, однако.
Давай дальше поговорю (Кстати, "талдонить" - нет такого слова. Есть слово "Талдычить". Это так, для сведения).

Ещё раз утверждаю, что здесь не обойтись без системных средств синхронизации. В данном случае именно без критических секций.

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

> Ответь на вопрос: какова цель использования критических
> секций?

Ты думаешь, я специально для тебя ликбез проводить буду? В ветке красной нитью мысль об этом проходит. достаточно внимательно прочитать высказывания оппонентов и владеть предметом дискуссии.

> MsGuns © (18.06.08 09:45) [46]
> >Тын-Дын © (18.06.08 00:50) [44]
>
> Ты случаем не академик ? А то стиль вещания очень академический:
> мол делай как я сказал - иначе могила.

Нет, не академик. Но то, о чем говорю, знаю. А не игнорирую, как ты, логику и опыт.

> ANB (18.06.08 10:19) [47]
>
> > лишь заметил, что в можно отработать и через SendMessage
>
> Все верно. Это всего лишь другой подход к синхронизации.
> Позволяет обойтись без критических секций (во всяком случае
> - своих).
> Это я для Тын-Дын ©.

Ну я ж написал выше, почему нельзя использовать SendMessage(как и PostMessage). Это может быть верно для единственного дополнительного потока.

> Милин, а почему когда я попробовал так делать, у меня AV
> лезли ?

Ну так всё верно. Если многопоточная программа написана неправильно - AV и будут. В лучшем случае.

← →
Игорь Шевченко © (2008-06-18 12:56) [49]

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

← →
Palladin © (2008-06-18 13:07) [50]

> Тын-Дын © (18.06.08 12:41) [48]

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

Для монопольного доступа к каким либо разделяемым ресурсам они нужны. Второй вопрос, зачем нам этот монопольный доступ? В одном случае, что бы считать данные, в другом, что бы считать/записать. Зачем главному потоку считывать данные? Что бы отобразить. Каким попом это будет происходить? Критические секции не занимаются отображением данных. Как их (данные) отображать? Всю ветку ты распинаешься про КС, а о том как же данные отобразить, когда их отобразить, так ничего и не сказал, кроме того, что нужно нажимать на кнопку. Вопрос то читал?

> Ещё раз утверждаю, что здесь не обойтись без системных средств
> синхронизации.

Еще раз утверждаю, что я не утверждаю обратное. Всеми руками за! Ты можешь понять такую простейшую мысль, что мой пост про таймеры и отдельный поток-монитор, подсказывают как отображать периодически?
Противопоказаний к использованию SendMessage, вот честно, не вижу. Огромные посты к этому не предрасполагают. Если не трудно, тыкни носом.

← →
Sapersky (2008-06-18 13:37) [51]

Работа с байтом - всегда атомарная операция, потому до сих пор и не возникало проблем. Замени на Integer - получишь проблемы очень скоро.

Хм, интересно, откуда такая разница между байтом и Integer? Процессоры уже давно как минимум 32-битные, т.е. никакой разницы в атомарности быть не должно. Ну может быть, от выравнивания зависит, хотя здесь точно не в курсе (зависит от того, как операции с невыровненными данными разбиваются на две - на уровне процессора или компилятора).
AFAIK, чтение Integer - потокобезопасно, при условии, что пишет его один поток (или несколько с использованием Interlocked), за исключением некоторых моментов, относящихся к многопроцессорным/многоядерным машинам:
http://msdn.microsoft.com/en-us/library/ms686355(printer).aspx

Начиная с P1, есть команда процессора, позволяющая атомарно модифицировать или прочитать 8 байт (cmpxchg8b), на ней основаны 64-битные Interlocked-функции последних версий Windows. Впрочем, Interlocked-функции можно писать и самостоятельно:
http://msdn.microsoft.com/en-us/magazine/cc302329(printer).aspx
и использовать в любой Win. Для Дельфи:
http://qc.borland.com/wc/qcmain.aspx?d=6212

← →
Тын-Дын © (2008-06-18 13:38) [52]

> Palladin © (18.06.08 13:07) [50]

> Для монопольного доступа к каким либо разделяемым ресурсам
> они нужны.

И всё? тогда точно ликбез не повредит.

Для чего нужен монопольный доступ? - Это лишь средство записать или получить корректные данные, т.е. согласованные логически.

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

> можешь понять такую простейшую мысль, что мой пост про таймеры
> и отдельный поток-монитор, подсказывают как отображать периодически?
>

Тебя спрашивали об этом?

> Противопоказаний к использованию SendMessage, вот честно,
> не вижу

Читай выше.

> Огромные посты к этому не предрасполагают. Если не трудно,
> тыкни носом.

Нет уж. Прежде чем воду лить, потрудись прочитать.

И почитай уже какую-нибудь книжку, что-ли. Для самообразования.

← →
Тын-Дын © (2008-06-18 13:41) [53]

> Sapersky (18.06.08 13:37) [51]
> Работа с байтом - всегда атомарная операция, потому до сих
> пор и не возникало проблем. Замени на Integer - получишь
> проблемы очень скоро.
>
> Хм, интересно, откуда такая разница между байтом и Integer?
> Процессоры уже давно как минимум 32-битные, т.е. никакой
> разницы в атомарности быть не должно.

А как насчет операций суммирвания и прочих? они тоже атмарные?
int1 := ((int2 div 8) + Int3)*int4;

← →
Sapersky (2008-06-18 14:30) [54]

В контексте многопоточности говорить о сложении-вычитании смысла нет. Имеет значение:
1) Чтение или запись (+ сколько потоков пишет)
2) Размер данных (+ связаны ли данные)
Что вы хотели показать своим примером? Там есть и чтение и запись, но какая переменная к какому потоку относится, сколько потоков выполняют этот код - не уточнено.

← →
Leonid Troyanovsky © (2008-06-18 14:47) [55]

> oxffff © (17.06.08 22:35) [27]

> Поток чтения может обращаться к shared данным напрямую.

Может. Например, FTerminated во-ще ничем не защищено.

> Если нет зависимого чтения, то InterLocked* не нужны.

> Это все естественно для случая когда вы читаете сырые данные
> без привязки к какому либо моменту.

Слишком много "если" для Начинающим.
Зависимы ли опрашиваемые данные - это еще вопрос.

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

--
Regards, LVT.

← →
MsGuns © (2008-06-18 15:35) [56]

Блин, я ему про Фому, а он про Ерему. Какая критичность может быть в той схеме, что я описал ? Если каждый поток СОЗДАЕТ СВОЙ РЕКОРД, адрес которого добавляет в список всех рекордов (единственное, что нуждается в синхронизации) - никто другой не должен туда ПИСАТЬ. А ЧИТАЕТ оттуда гл.поток, который использует этот рекорд для извлечения данных для отображения. Если гл.поток сунется (по таймеру) в рекорд ДО ТОГО, КАК ПОТОК ЗАКОНЧИТ ТУДА ЗАПИСЬ, то в худшем случае отобразится не вся информация, а ее "кусок", что проявится только в том случае если эта запись содержит какие-нибудь огроменные объекты типа списков или массивов - но я вот ума не приложу зачем эту офигень ОТОБРАЖАТЬ ? Причем тут сихронизация, а тем более какие-то КС ? Где может быть AV, если с одного места пишется, а с другого читается ОДИН И ТОТ ЖЕ участок памяти ? Где тут взоврется ?
А глюки могут быть, конечно. Если, к примеру, запутать потоки, заставив их обращаться не к "своим" записям - но это данном случае трудно сделать нечаянно.

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

Одно слово - академик ;)

← →
Тын-Дын © (2008-06-18 16:20) [57]

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

Вот блин, и этот про Фому.
Так "талдонить" или "долдычить"?
Читать умеешь?

PS.

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

← →
MsGuns © (2008-06-18 16:47) [58]

>Тын-Дын © (18.06.08 16:20) [57]
>Не пиши больше бред про синхронизацию, пожалуйста, признавая, что ты сам >получаешь вместо данных из потоков бред.
>Если тебя это устраивает - это твои личные тараканы. Не надо размножать их в инете.

Экой ты смешной, друже ;) Устраивает не меня, а пользователей, и написанное вовсе не бред. На бред больше похожи твои теоретические изыски под девизом "так делать низзя ибо будет бо-бо", к сабжу имеющие весьма отдаленное отношение.

Если ты хочешь рассказать про синхронизацию и, особенно, про КС (а ведь тебя просили !), то либо расскажи и просвяти неучей, либо не "размножай в инете" свои домыслы.

← →
Тын-Дын © (2008-06-18 17:25) [59]

> Если ты хочешь рассказать про синхронизацию и, особенно,
> про КС (а ведь тебя просили !),

А я написал свои домыслы палладину. Мало разве?

> Экой ты смешной, друже ;) Устраивает не меня, а пользователей,
> и написанное вовсе не бред.

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

> На бред больше похожи твои теоретические изыски под девизом
> "так делать низзя ибо будет бо-бо", к сабжу имеющие весьма
> отдаленное отношение.

Мои практические советы имеют к теме топика самое непосредственное отношение (В отличие от твоих отвлечённых -"В моей программе так работает"ю А вот у ANB - не работает так. Почему бы это?).

← →
MsGuns © (2008-06-18 19:59) [60]

>Тын-Дын © (18.06.08 17:25) [59]
>Понимаешь, твой частный случй - это именно частныйслучай.
>Ты же пытаешься распространить его на общее, что является >категорически неправильным и вредным.

? Читаем мой пост, который вызвал у тебя такую реакцю:

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

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

>Мои практические советы имеют к теме топика самое непосредственное >отношение

ИМХО, мой пример более непосредственно относится именно к топику (по крайней мере как я его понял) именно как частный случай, который не требует сложного кода с кучей try except/finally и реализуется по весьма тривиальной схеме - потоки сами по себе что-то пишут в свои собственные переменные, а гл. поток периодически ревизует эти переменные и в соответствии с ними отображает текущий статус потока (или точнее, шал алгоритма, которым занимается поток в данный момент времени) напрмер, в сетке.
Для начинающего это много проще и не требует капитального въезжания в сам процесс синхронизации, который интуитивно малопонятен человеку, не знакомому с принципами работы процессора и ОС

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

← →
MsGuns © (2008-06-18 20:16) [61]

А вот другая схема, построенная не на опросе "мамы" деток", а на оповещении "детками" "мамы" о завршении ими какого-то целостного блока алгоритма:
В этом случае главный поток ("мама") никого не опрашивает (ессно, таймер тут побоку), а вот потоки ("дочки") по завершению блока сообщают об этом событии "маме". Вот тут как раз нужны и КС и синхронизация дабы "доклады" "деток" не "перепутывались". Но в этом случае "мама" будет весьма в затруднительном положении - каким образом ей перерисовывать на канве ту же сетку, если "доклады" будут сыпаться как из Рога изобилия - сетка просто будет безбожно моргать либо периодически подмаргивать, что будет не просто заметно визуально - это будет раздражать глаза.
Именно поэтому в ДАННОМ случае я и выбрал систему опроса, а не оповещения.
Вот если бы визуализации не было (например, если идет мониторинг запросов к скл-серверу, но отображаются только завершенные процессы), а вместо этого "мама" должна была бы сделать что-то невизуальное, но своевременное (например послать сообщение об изменении статуса запроса по сети) - вот тогда да, метод "опроса" глючен по своей сути, и вместо него следует применить метод "оповещения".

← →
Игорь Шевченко © (2008-06-18 23:40) [62]

Вам бы сказки писать - Шарль Перро в гробу бы перевернулся от зависти.

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

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

← →
MsGuns © (2008-06-19 09:16) [63]

>Игорь Шевченко © (18.06.08 23:40) [62]
>Вам бы сказки писать - Шарль Перро в гробу бы перевернулся от зависти.

Да ты, Игорь, тоже не пальцем делан :)

← →
Игорь Шевченко © (2008-06-19 09:40) [64]

MsGuns © (19.06.08 09:16) [63]

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

← →
vint45 (2008-06-19 12:34) [65]

кто-то аффтара спрашивал? здесь я.. чуствствую себя как приглашенный гость на передаче у позднера.
можно я со своей колокольни? только не ругайте сильно, я ведь только учусь

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

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

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

4. О Событиях. Опять же в моем понимании, в общем случае событие это механизм позволяющий приостановить работу всех потоков процесса, кроме потока, который инициировал ожидание этого события.
Поэтому, если мы будем инициировать ожидание события из основного потока, то получаем остановку выполнения всех доп. потоков, и делаем опять же через основной поток считывание переменных. Но так как переменные в доп. потоках в этот момент не синхронизированы, то мы можем считать абракатабру.
При вызове ожидания события из доп. потоков, все проходит вроде как шоколадно. Доп. поток вызывает ожидание, пишет синхронизированные данные в переменные основного потока, и после этого вызывает само событие, запускающие остальные потоки. Здесь смущает только то, что основной поток (да и остальные) будет часто простаивать, так как доп. потоков может быть не мало. И этот простой может оказаться критичным с точки зрения управления приложением.

← →
DVM © (2008-06-19 12:44) [66]

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

Как нет? Основной поток опрашивает переменные дополнительного.

← →
DVM © (2008-06-19 12:45) [67]

> Так как доп. потоки при выполнении этой КС простаивать не
> будут(так сами не вызывают эту КС)

так надо сделать, чтобы тоже они работали через крит секцию иначе труба.

← →
DVM © (2008-06-19 12:55) [68]

> vint45

Я не понимаю, в чем проблема сделать так, чтобы внутри метода Execute обращение к переменным было реализовано через свойства, защищенные КС.

interface uses Classes, SyncObjs; type TTestThread = class(TThread) private FParam: integer; FCriticalSection: TCriticalSection; procedure SetParam(AParam: integer); function GetParam: integer; protected procedure Execute; override; public constructor Create(CreateSuspended: boolean); destructor Destroy; override; prorerty Param: integer read GetParam write SetParam; end; implementation constructor TTestThread.Create(CreateSuspended: boolean); begin FCriticalSection := TCriticalSection.Create; inherited Create(CreateSuspended); end; destructor TTestThread.Destroy; begin FCriticalSection.Free; inherited Destroy; end; procedure TTestThread.SetParam(AParam: integer); begin FCriticalSection.Enter; try FParam := AParam; finally FCriticalSection.Leave; end; end; function TTestThread.GetParam: integer; begin FCriticalSection.Enter; try result := FParam; finally FCriticalSection.Leave; end; end; procedure TTestThread.Execute; begin Param := 0; while not Terminated do begin Param := Param + 1; sleep(100); end; end;

← →
MsGuns © (2008-06-19 14:31) [69]

>Игорь Шевченко © (19.06.08 09:40) [64]

Подходит схема "опроса", т.е. КС и снхронизация не обязательны (и даже могут быть вредны, ибо тормозят)

← →
Тын-Дын © (2008-06-19 14:36) [70]

> Игорь Шевченко © (19.06.08 09:40) [64]
> MsGuns © (19.06.08 09:16) [63]
>
> Серега, смотри сам - если у тебя, допустим, N потоков занимаются,
> ну скажем закачкой файлов и в "локальных переменных" хранят
> прогресс этой самой закачки, а главный поток натурально
> этот прогресс в красивом виде отображает. Неужели в этом
> случае требуется супер-пупер синхронизация с критическими
> или некритическими секциями ?

Не супер-пупер, а обычная синхронизация требуется.

> MsGuns © (19.06.08 14:31) [69]
> >Игорь Шевченко © (19.06.08 09:40) [64]
>
> Подходит схема "опроса", т.е. КС и снхронизация не обязательны
> (и даже могут быть вредны, ибо тормозят)

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

> vint45 (19.06.08 12:34) [65]

> 2. Главная задача состоит в корректном (синхронизированном)
> копировании значений переменных доп. потоков к основному
> потоку приложения (передача статданных в основной поток
> для последующего отображения в форме главного потока).
> Копирование значений переменных абы как, без синхронизации,
> или согласованности (не знаю как правильнее сказать, т.
> е. без проверки на то, что будут скопированы реальные значения
> переменных) считаю неправильным.

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

От этого зависит подход к решению задачи.

← →
vint45 (2008-06-19 15:14) [71]

> DVM © (19.06.08 12:55) [68]

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

> Тын-Дын ©

Мне важно выполнять корректное присвоение переменным основного потока. Каким образом это лучше сделать (получать данные основным потоком или доп. потоками), я пока не знаю. Хотя DVM привел, на мой взгляд, хороший пример.

← →
DVM © (2008-06-19 15:18) [72]

> vint45 (19.06.08 15:14) [71]

> Соответственно чтение и запись одновременно выполняться
> не могут.

Так это и требуется. Иначе бардак будет.

← →
Игорь Шевченко © (2008-06-19 15:30) [73]

Тын-Дын © (19.06.08 14:36) [70]

> Не супер-пупер, а обычная синхронизация требуется.

Нахрен не сдалась.

Мы не в синагоге, нам кошерность не требуется, а требуется решение задачи. Каковая задача до сих в пор в понятном виде не озвучена.

← →
Тын-Дын © (2008-06-19 15:41) [74]

> Мы не в синагоге, нам кошерность не требуется, а требуется
> решение задачи. Каковая задача до сих в пор в понятном виде
> не озвучена.

Требуется не кошерность, а тривиальное - неразрушенные данные.
Без синхронизации (любым способом) этоневозможно. За исключением записи и чтения переменных размером в 1 байт.

← →
Игорь Шевченко © (2008-06-19 15:49) [75]

Тын-Дын © (19.06.08 15:41) [74]

> Требуется не кошерность, а тривиальное - неразрушенные данные.

Еще раз, медленно и печально. Допустим, есть несколько потоков, занимающихся закачкой файлов. Для каждого файла известен его полный размер и размер текущего закаченного содержимого. Каждый файл качается своим потоком, соотв. оба размера являются локальными переменными этого потока. Еще один поток (главный, неглавный, неважно) занимается отображением прогресса скачивания файлов (Napster или FlashGet или eMule или Torrent видел ? - так вот у бабочек то же самое).
Соответственно, этот поток опрашивает локальные переменные (размер скачанной части) каждого потока и красиво выводит в Progress bar, можно даже с градиентом.

Локальные пременные могут быть длиной либо 32 бита, либо 64.

Какие тут могут быть разрушенные данные ?

← →
Тын-Дын © (2008-06-19 15:50) [76]

> MsGuns ©

> Игорь Шевченко ©

Для демонстрации схематичный пример потока.

type TCopier=class(TThread) private FSize: int64; //Размер всех скопированных файлов LastFileSize: int64; //Размер последнего скопированного файла LastFileName: String; //Имя последнего скопированного файла procedure Copy; //Процедура копирования protected procedure Execute; override;

Данные (Например, Private-Fields)из нескольких запущенных потоков должны попадать в основной поток и отображаться, затем сохраняться в журнал (основной поток).

Без синхронизации всякие размышления об этом бесмысленны.

← →
Игорь Шевченко © (2008-06-19 15:52) [77]

Тын-Дын © (19.06.08 15:50) [76]

Просьба на [75] ответить

← →
Тын-Дын © (2008-06-19 15:52) [78]

> Еще раз, медленно и печально.

Можно побыстрее и не так печально. Смысл от этого не изменится. и необходимость в синхронизации тоже.
Игорь, тебе-то уж об этом задумываться - нужно-не нужно... Даже неудобно как-то.

← →
Тын-Дын © (2008-06-19 15:53) [79]

>
> Просьба на [75] ответить

Я на [75] в [76] ответил.

← →
Игорь Шевченко © (2008-06-19 15:56) [80]

Тын-Дын © (19.06.08 15:52) [78]

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

качающий поток:
type
size_t = int64;

TDownloadThread = class(TThread)
private
FTotalSize: size_t;
FCurrentSize: size_t;
.........
public
property TotalSize: size_t read FTotalSize;
property CurrentSize: size_t read FCurrentSize;
.......
end;

меняется в процессе загрузки, сам понимаешь, только FCurrentSize;

← →
Игорь Шевченко © (2008-06-19 15:56) [81]

> Я на [75] в [76] ответил.

нет, извини, ты ответил на нечто иное.

← →
DVM © (2008-06-19 15:58) [82]

> Какие тут могут быть разрушенные данные ?

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

Но так только в этом конкретном случае.

← →
Тын-Дын © (2008-06-19 16:03) [83]

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

Корректное-ли? весли чтение происходит в процессе записи числа, то как в этом можно быть уверенным? И не AV-ли получим?

← →
Тын-Дын © (2008-06-19 16:04) [84]

> Игорь Шевченко © (19.06.08 15:56) [81]
>
> > Я на [75] в [76] ответил.
>
>
> нет, извини, ты ответил на нечто иное.

Почему ты считаешь, что твой пример отражает авторский вопрос и более точен?
К тому же см. [83]. Как раз тут и возможно разрушение данных.

← →
Тын-Дын © (2008-06-19 16:05) [85]

+ к тому:
С чего ты взял, что получить необходимо только одну переменную?

← →
Игорь Шевченко © (2008-06-19 16:05) [86]

DVM © (19.06.08 15:58) [82]

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

что значит "перезаписаны некоторые байты" ?

Тын-Дын © (19.06.08 16:03) [83]

> весли чтение происходит в процессе записи числа, то как
> в этом можно быть уверенным? И не AV-ли получим?

Интересно, каким образом можно получить AV ?

← →
Тын-Дын © (2008-06-19 16:06) [87]

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

> Интересно, каким образом можно получить AV ?

интересно, Int64 пишет срзу 8 байт? На всех процессорах? Всегда?

← →
DVM © (2008-06-19 16:07) [88]

> Корректное-ли?

А почему нет? Область памяти зарезервирована под это число, там лежат какие-то прошлые данные представляющие собой число, часть байт перезаписывается, но все равно по данному адресу продолжает лежать число.

> И не AV-ли получим?

Не, не получим. Хотя можно попробовать смоделировать ситуацию.

← →
Игорь Шевченко © (2008-06-19 16:07) [89]

Тын-Дын © (19.06.08 16:04) [84]

Мой пример отражает только мой пример [64] и ничего более. В [70] ты ответил: "Не супер-пупер, а обычная синхронизация требуется."
Вот просьба пояснить мне и остальным участникам, какого рода синхронизация требуется и зачем ?

← →
Игорь Шевченко © (2008-06-19 16:08) [90]

> интересно, Int64 пишет срзу 8 байт? На всех процессорах?
> Всегда?

пусть он пишет по 32 бита

← →
DVM © (2008-06-19 16:09) [91]

> Игорь Шевченко © (19.06.08 16:05) [86]

> что значит "перезаписаны некоторые байты" ?

Вторичный поток начал запись нового значения, скажем в 4-х байтовое число, записал только 2 байта и управление было передано основному потоку, который считал два старых байта и 2 новых. Или такое невозможно?

← →
Тын-Дын © (2008-06-19 16:09) [92]

> пусть он пишет по 32 бита

Один поток пишет int64, в это время второй читает. 32 бита от старого значения, 32 - от нового.

← →
Игорь Шевченко © (2008-06-19 16:10) [93]

Тын-Дын © (19.06.08 16:09) [92]

И чего ? Где AV ?

← →
Тын-Дын © (2008-06-19 16:10) [94]

> Игорь Шевченко © (19.06.08 16:07) [89]
> Тын-Дын © (19.06.08 16:04) [84]
>
> Мой пример отражает только мой пример [64] и ничего более.
> В [70] ты ответил: "Не супер-пупер, а обычная синхронизация
> требуется."
> Вот просьба пояснить мне и остальным участникам, какого
> рода синхронизация требуется и зачем ?

Из примера в [76] разве не видно? Нужно разжевывать?

← →
MsGuns © (2008-06-19 16:10) [95]

Из пустого в порожнее ;(

← →
Игорь Шевченко © (2008-06-19 16:11) [96]

Демонстрационный пример с AV приветствуется...

> MsGuns © (19.06.08 16:10) [95]
> Из пустого в порожнее ;(

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

Тын-Дын © (19.06.08 16:10) [94]

> Нужно разжевывать?

Меня не интересует пример [76], меня интересует пример [80]. Нефигово бы разжевать

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

слово "связынных" внесено в задачу тобой, это раз. Слово "связанных" вовсе не подразумевает их, обоих, изменения. В моем примере 80 переменные как раз связанные, но меняется только одна из них.

> Меня не интересует пример [76], меня интересует пример [80].
> Нефигово бы разжевать

1. Твой пример, ты и разжуй (с учетом [92]), как ты получишь правильное значение.
2. Раз [76] не нужен пример, то тогда и не говори про то, что синхронизация не нужна. Бледно выглядит.

> Игорь Шевченко © (19.06.08 16:14) [99]
>
> > При необходимости получения нескольких связанных переменных
>
> > из другого потока необходима синхронизация.
>
>
> слово "связынных" внесено в задачу тобой, это раз. Слово
> "связанных" вовсе не подразумевает их, обоих, изменения.
> В моем примере 80 переменные как раз связанные, но меняется
> только одна из них.

В твоем примере [80]не связанные int64. При одновременных чтении и записи ты не получишь корректных данных.

Если это не так, то докажи.

Я об этом написал в [92].

> Игорь Шевченко © (19.06.08 16:15) [101]
> Тын-Дын © (19.06.08 16:14) [100]
>
>
> > Твой пример, ты и разжуй
>
>
> Слив защитан

Когда нет доказательств, начинается демагогия.

> Когда нет доказательств, начинается демагогия.

В зеркало.

> В твоем примере [80]не связанные int64. При одновременных
> чтении и записи ты не получишь корректных данных.
>
> Если это не так, то докажи.

Бремя доказательства лежит на утверждающем. Догматизм - не самая полезная черта при программировании.

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

← →
vint45 (2008-06-19 17:11) [105]

> DVM © (19.06.08 16:09) [91]
> Вторичный поток начал запись нового значения, скажем в 4-
> х байтовое число, записал только 2 байта и управление было
> передано основному потоку, который считал два старых байта
> и 2 новых. Или такое невозможно?

Игорь можно получить комментарии на этот пост?

vint45 (19.06.08 17:11) [105]

> Игорь можно получить комментарии на этот пост?

Всенепременно можно. Инструкция записи 4-х байтового числа не прерывается после записи/чтения каждого байта. Синхронизация доступа к памяти при выполнении разых потоков на разных процессорах осуществляется аппаратно.

Но дело даже не в этом. Дело в том, что процесс отображения прогресса чего-либо не требует непременно согласованных данных в каждый момент отображения.

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

> 2. Главная задача состоит в корректном (синхронизированном)
> копировании значений переменных доп. потоков к основному
> потоку приложения (передача статданных в основной поток
> для последующего отображения в форме главного потока).
> Копирование значений переменных абы как, без синхронизации,
> или согласованности (не знаю как правильнее сказать, т.
> е. без проверки на то, что будут скопированы реальные значения
> переменных) считаю неправильным.

1. Разве речь идет о прогрессбарах?

> Всенепременно можно. Инструкция записи 4-х байтового числа
> не прерывается после записи/чтения каждого байта. Синхронизация
> доступа к памяти при выполнении разых потоков на разных
> процессорах осуществляется аппаратно.

Можно ли утверждать это про int64?

Тын-Дын © (19.06.08 17:31) [107]

Ветку читай внимательно. Ты все время перескакиваешь с одной постановки задачи на другую.

> Можно ли утверждать это про int64?

проверь

> vint45 (19.06.08 15:14) [71]

> Мне важно выполнять корректное присвоение переменным основного
> потока.

Synchronize forever. (Or SendMessage :)

Хотя, лучше б ты определился, а то видишь, какаие страсти
могут разгореться из-за неточностей формулировки.

--
Regards, LVT.

> Ветку читай внимательно. Ты все время перескакиваешь с одной
> постановки задачи на другую.

Игорь, про прогрессбар ни я, ни атор в ветке не говорил ни разу.
Уточнение от втора есть. Прогрессбара - нет.

Да и не в нём дело.
Проверять как записывается Int64 - это означает изучать ассемблер. Ну нет такого желания. Да и незачем вроде пока.
Впрочем, не только Int64 может использоваться в дополнительных потоках.
Очень часто используется также тип String и т.п.
Что, каждый раз, для того, чтобы быть уверенным, что операция атомарная, нужно изучать линейку процессоров от мшистых дней до наших, их команды и архитектуру?

Есть четкое понятие - при одновременном доступе к данным (изменении и чтении) необходима синхронизация доступа.
И тут даже доказыватьничего не надо.
Не надо из частного вырожденного примера делать выводы, которые нужны только применительно к одному частному примеру.
Общее правило - синхронизация нужна.
Для чего ты пытаешься доказать обратное?

> Игорь Шевченко © (19.06.08 16:14) [99]

> слово "связынных" внесено в задачу тобой, это раз.

Извини, но понятие "зависимости" привнес уважаемый
oxffff © (17.06.08 22:35) [27] .
Причем, вполне корректно, и с нужным акцентом напомнив
полезную статью msdn.

Но, сути оно не меняет.

Предположим, что каждый поток собирает данные,
скажем, о температуре, давлении и др.
А первичный поток это по запросу показывает оператору,
который и принимает решение о нажатии некоторой кнопки.

Согласись, что данные получаемые "несогласованным"
способом могут его обмануть.

Даже если мы не подозреваем о зависимости получаемых
данных (и не видим ее в коде), то лучше получать их так,
чтобы не искажать их объективную картину.
Synchronize forever.

Кста, совсем не обсуждался вопрос: а нужны ли здесь потоки.

--
Regards, LVT.

> Leonid Troyanovsky © (19.06.08 18:15) [111]

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

> oxffff © (19.06.08 18:26) [112]

> Я думаю автор запускает свои потоки на однопроцессорной
> машине(пусть и многоядерной) поэтому эта проблема его не
> коснется.

Коснется, коснется :)

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

Про мобильные тоже было трудно представить.

--
Regards, LVT.

← →
ANB (2008-06-19 18:44) [114]

> Кста, совсем не обсуждался вопрос: а нужны ли здесь потоки.

Вот млин. Я же обычно с этого и начинаю.

Если файлы загружаются с локала - то от многопоточности толку будет немного.

> Кста, совсем не обсуждался вопрос: а нужны ли здесь потоки.

Так а какая разница?
Может быть многопоточная закачка с инет-сервера, копирование с сетевых ресурсов. Для любой их этих задач распараллеливание работ - вполне нормальная вещь.

> ANB (19.06.08 18:44) [114]
>
> > Кста, совсем не обсуждался вопрос: а нужны ли здесь потоки.
>
>
> Вот млин. Я же обычно с этого и начинаю.

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

← →
Sapersky (2008-06-19 19:15) [116]

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

Точно только многопроцессорных?
Насколько я понял, проблема возникает из-за особенностей реализации передачи данных из памяти в кэш и обратно. А если у двухъядерника раздельный кэш, то передачу данных от одного ядра другому придётся делать через системную память, так же, как и на двухпроцессорной машине. И проблемы (теоретически) должны быть те же самые.
Кстати, даже у CoreDuo c его общим кэшем в этом плане не всё гладко:
http://www.fcenter.ru/online.shtml?articles/hardware/processors/17685

Тын-Дын © (19.06.08 17:59) [110]

Я начал с того (вообще), что автор никаким боком не объясняет, какую задачу он решает. В качество одного примера (только лишь одного), привел ситуацию, когда синхронизация будет только тормозами, не играя никакой роли в решении задачи. Я не пытался решить ни задачу автора (я ее попросту не знаю), ни какую либо еще, кроме той, что привел в своем примере (об отображении прогресса многопоточной закачки файлов, с конкретными данными). Дабы не углубляться в изучение ассемблера, я могу сказать, что файлы больше 4-х гиг скачиваться в принципе не могут, а еще лучше, что локальными переменными потока являются уже посчитанные проценты, в диапазоне от 0 до 100, 32-х бит вполне достаточно.
И что процент скачивания одного файла одним потоком никак не связан с процентом скачивания другого файла другим потоком.

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

> Sapersky (19.06.08 19:15) [116]

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

Общий кэш второго уровня означает, что данные, прочитанные первым ядром в кэш L2, автоматически должны быть "видны" второму ядру, что позволяет нам рассчитывать на получение очень хороших результатов. Давайте на них посмотрим.

> Не надо из частного вырожденного примера делать выводы,
> которые нужны только применительно к одному частному примеру.
>
> Общее правило - синхронизация нужна.
> Для чего ты пытаешься доказать обратное?

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

Вот же блин - достал пиво из холодильника, а оно вспенилось. Нет в жизни счастья.

> Вот же блин - достал пиво из холодильника, а оно вспенилось.
> Нет в жизни счастья.

А я молоко пью оно полезней и не пенится. :)
Присоединяйтесь.

oxffff © (19.06.08 19:51) [120]

Не, молоко после тяжелого жаркого дня не спасает.

Кстати, о кэшах и многоядерности, я надеюсь, в статье написано о том, что и доступ к памяти и доступ к кэшу несколькими ядрами синхронизирован ?

> Игорь Шевченко © (19.06.08 19:54) [121]

Я честно говоря не читал эту статью.
Если возникнет необходимость, то я Memory Coherency and Protocol в документации на процессор. Например в AMD это MOESI.
И документацию у меня тоже имеется. :)

> Я честно говоря не читал эту статью.

У меня сейчас голова думает "Надо пойти профиля прикрутить на потолок".

← →
Sapersky (2008-06-19 20:25) [124]

Общий кэш второго уровня означает, что данные, прочитанные первым ядром в кэш L2, автоматически должны быть "видны" второму ядру, что позволяет нам рассчитывать на получение очень хороших результатов. Давайте на них посмотрим.

Давайте, посмотрим:
"Отсюда следует поразительный вывод: доступ к модифицированным данным, расположенным в кэше первого уровня другого ядра, происходит по тем же самым принципам, что и доступ к данным в кэшах ядер процессоров Athlon 64 X2 и Pentium D. То есть последняя действительная копия данных сначала отправляется на запись в оперативную память через системную шину, а затем передаётся обратно во второе ядро."

Т.е. в общем обмен между ядрами у CoreDuo получше, чем у других, но в некоторых случаях всё равно идёт через память.
И, собственно, программы ведь пишутся не только для CoreDuo, но и для этих "других" тоже, нет?

> Sapersky (19.06.08 20:25) [124]
> Общий кэш второго уровня означает, что данные, прочитанные
> первым ядром в кэш L2, автоматически должны быть "видны"
> второму ядру, что позволяет нам рассчитывать на получение
> очень хороших результатов. Давайте на них посмотрим.
>
> Давайте, посмотрим:
> "Отсюда следует поразительный вывод: доступ к модифицированным
> данным, расположенным в кэше первого уровня другого ядра,
> происходит по тем же самым принципам, что и доступ к данным
> в кэшах ядер процессоров Athlon 64 X2 и Pentium D. То есть
> последняя действительная копия данных сначала отправляется
> на запись в оперативную память через системную шину, а затем
> передаётся обратно во второе ядро."

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

>
> Т.е. в общем обмен между ядрами у CoreDuo получше, чем у
> других, но в некоторых случаях всё равно идёт через память.
>

Я частенько появляюсь в конференции "Процессоры" на Ixbt, но в основном в качестве зрителя. Не хочу выглядить профаном.
Там какие изречения не любят. Уж больно дядьки серьезные.
Получше это как?

> И, собственно, программы ведь пишутся не только для CoreDuo,
> но и для этих "других" тоже, нет?

Да, и что дальше? :)

← →
Sapersky (2008-06-19 20:50) [126]

Я вообще-то не собирался обсуждать приведённую статью. Меня больше интересует, на каком основании сделан вывод, что Synchronization and Multiprocessor Issues не распространяются на многоядерные системы.
Статья приведена только для того, чтобы показать, что обмен между ядрами в двухядерниках часто идёт через системную память, и, по моему разумению, они в этом смысле не отличаются принципиально от двухпроцессорных систем.

← →
Sapersky (2008-06-20 11:18) [127]

Если возникнет необходимость, то я Memory Coherency and Protocol в документации на процессор. Например в AMD это MOESI.

Не подскажешь страничку, где конкретно сказано, что в многоядерных процессорах одно ядро "видит" запись в память строго в том порядке, в каком пишет другое?
Собственно в MOESI ничего такого не нашёл, там общие принципы синхронизации содержимого кэшей.

> Sapersky (20.06.08 11:18) [127]

Читай внимательно oxffff © (19.06.08 19:46) [118].
Автоматически тебе ничего не говорит?

>Sapersky (20.06.08 11:18) [127]

http://www.oszone.ru/3503/Dual

Каждое из ядер Athlon 64 X2 обладает собственным набором исполнительных устройств и выделенной кэш-памятью второго уровня; контроллер памяти и контроллер шины HyperTransport общие. А вот взаимодействие каждого ядра с разделяемыми ресурсами происходит посредством специального коммутатора (Crossbar Switch) и интерфейса системных запросов (System Request Interface), в котором формируется очередь системных запросов (System Request Queue). И, что самое главное, на этом же уровне организовано и взаимодействие ядер, благодаря чему вопросы когерентности кэшей решаются без дополнительной нагрузки на системную шину и шину памяти.

← →
Sapersky (2008-06-20 19:29) [130]

Нашёл пресловутую страницу в документации (Multiprocessor Memory Access Ordering).
Правда, не вполне понятно, относится ли AMD"шное "Multiprocessor" только к многоядерным или к многопроцессорным системам тоже. Intel в соответствующем документе уточняет: "The term processor refers to a logical processor, which may be one processing component of a hyperthreaded physical processor or of a multi-core physical package.", т.е. вроде как только про многоядерники.

> Sapersky (20.06.08 19:29) [130]
> Нашёл пресловутую страницу в документации (Multiprocessor
> Memory Access Ordering).

И что в этой странице пишется?

← →
Sapersky (2008-06-20 19:48) [132]

Loads do not pass previous loads (loads are not re-ordered). Stores do not pass previous stores (stores are not re-ordered).

In the examples below all memory values are initialized to zero.

Processor 0 Processor 1
Store A ← 1 Load B
Store B ← 1 Load A

Load A cannot read 0 when Load B reads 1.

Тот же пример, что и у микрософта, с двумя зависимыми переменными, но с положительным результатом.

> Sapersky (20.06.08 19:48) [132]

А можно пример полностью или № документ или ссылка на документ со страницей. А то выдран из непонятного контекста.

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

← →
Sapersky (2008-06-21 09:12) [135]

А можно пример полностью или № документ или ссылка на документ со страницей. А то выдран из непонятного контекста.

AMD64 Architecture Programmer’s Manual Volume 2: System Programming
Memory System \ Multiprocessor Memory Access Ordering (стр. 164)
У Intel:
Intel® 64 Architecture Memory Ordering

Эта...господа спорящие,

Да никто уж не спорит (поначалу было немного - дык, дурной пример заразителен :)).
Лично я пытаюсь понять, к чему относится статья микрософта (где-то ранее была ссылка), если Intel/AMD в своих мануалах её фактически опровергают. Может, к каким-нибудь Alpha или PowerPC - тем лучше, конечно, но хотелось бы однозначно убедиться.

> AMD64 Architecture Programmer’s Manual Volume 2: System
> Programming

У меня такой есть.
Просмотрел весь 7 раздел. Но примера не нашел?
У меня
Publication No. Revision Date
24593 3.11 December 2005

А какая страница? :)

Меня смущает

>Loads do not pass previous loads (loads are not re-ordered). Stores do not >pass previous stores (stores are not re-ordered).

1. Implementations of the AMD64 architecture retire instructions
in program order, but implementations can execute instructions
in any order. ....
However, because implementations can execute
instructions out of order and speculatively, the sequence of memory accesses
can also be out of program order (weakly ordered).

For cacheable memory types, the following rules govern read
ordering:
Out-of-order reads are allowed. Out-of-order reads can occur
as a result of out-of-order instruction execution or
speculative execution. The processor can read memory outof-
order to allow out-of-order execution to proceed.

Reads can be reordered ahead of writes.
A read cannot be reordered ahead of a prior write if the read
is from the same location as the prior write.

Generally, out-of-order writes are not allowed. Write
instructions executed out of order cannot commit (write)
their result to memory until all previous instructions have
completed in program order. The processor can, however,
hold the result of an out-of-order write instruction in a
private buffer (not visible to software) until that result can
be committed to memory.

Write buffering is allowed. When a write instruction
completes and commits its result, that result can be buffered
before actually writing the result into a memory location in
program order. Although the write buffer itself is not
directly accessible by software, the results in the buffer are
accessible during memory accesses to the locations that are
buffered.

Write combining is allowed. In some situations software can
relax the write-ordering rules and allow several writes to be
combined into fewer writes to memory. When writecombining
is used, it is possible for writes to other memory
types to proceed ahead of (out-of-order) memory-combining
writes, unless the writes are to the same address. Writecombining
should be used only when the order of writes
does not affect program order

When the order of memory accesses must be strictly enforced,
software can use read/write barrier instructions to force reads
and writes to proceed in program order.

Однако

In some cases, data can be modified in a manner that is
impossible for the memory-coherency protocol to handle due to
the effects of instruction prefetching.

← →
Sapersky (2008-06-22 04:11) [137]

У меня поновее:
Publication No. Revision Date
24593 3.14 September 2007
стр. 164
Возможно, в 2005 г. и ранее всё так и было, как описано в старой
документации. Многопроцессорные системы имели известные проблемы, но в силу малой распространённости AMD предпочитал уповать на продвинутость пишуших под них программистов. Потом появились куда более популярные двухядерники, и AMD пришлось заткнуть наиболее опасные "дырки", чтобы не портить жизнь рядовым кодерам.
Версия всем хороша, кроме одного момента: первый Athlon X2 появился в апреле 2005-го. Н-ну, может быть, в AMD очень медленно пишут обновления к документации...

> Потом появились куда более популярные двухядерники, и AMD
> пришлось заткнуть наиболее опасные "дырки", чтобы не портить
> жизнь рядовым кодерам.

То есть так, как я и озвучивал выше. :)
Но с твоим доказательством. Спасибо.

Потоки. Нужна ли синхронизация? Найти похожие ветки