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

← →
Игорь Шевченко © (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 приветствуется...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тын-Дын © (19.06.08 16:14) [100]

> Твой пример, ты и разжуй

Слив защитан

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

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

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

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

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

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

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

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

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

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

В зеркало.

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

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

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

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

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

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

← →
Игорь Шевченко © (2008-06-19 17:28) [106]

vint45 (19.06.08 17:11) [105]

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

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

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

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

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

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

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

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

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

← →
Игорь Шевченко © (2008-06-19 17:45) [108]

Тын-Дын © (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, автоматически должны быть "видны" второму ядру, что позволяет нам рассчитывать на получение очень хороших результатов. Давайте на них посмотрим.

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

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

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

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

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

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