Нужна ли синхронизация когда потоки только читают?

← →
Кто б сомневался © (2014-11-24 05:07) [0]

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

Спасибо.

← →
MBo © (2014-11-24 05:56) [1]

Да.

Но ведь кто-то же в неё все-таки пишет, иначе не было бы смысла читать да читать?

← →
sniknik © (2014-11-24 08:04) [2]

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

← →
junglecat © (2014-11-24 08:38) [3]

> иначе не было бы смысла читать да читать?

справочники, настройки, ...

← →
KilkennyCat © (2014-11-24 11:56) [4]

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

← →
junglecat © (2014-11-24 11:59) [5]

> [4] KilkennyCat © (24.11.14 11:56)

многопоточность и гуй - это вообще отдельная история

← →
Кто б сомневался © (2014-11-24 13:30) [6]

> MBo © (24.11.14 05:56) [1]
>
> Да.
>
> Но ведь кто-то же в неё все-таки пишет, иначе не было бы
> смысла читать да читать?

Да не, все просто:

Создал массив со структурами, заполнил, создал 2 потока, читают данные оттуда.
Потоки отработали, массив уничтожили.

Что-то мне кажется при чтении не нужна синхронизация, в голове плотно эта мысль сидит, даже помню лет 5 назад код писал с учетом этого ньюанса.

← →
MBo © (2014-11-24 13:33) [7]

Да, в таком случае синхронизация не требуется

← →
junglecat © (2014-11-24 13:35) [8]

> [6] Кто б сомневался © (24.11.14 13:30)

"ньюанс" в том, что если кто-то будет писать в этот массив, то чтение без синхронизации чревато неактуальными или неполными данными.
наподобие read uncommited в БД

← →
Кто б сомневался © (2014-11-24 13:59) [9]

MBo © (24.11.14 13:33) [7]

Понятно. А такой вопрос, вдруг придется делать (обычно крит секциями закрываю, но здесь не желательно засыпание потоков).
Если один поток будет менять что-то в массиве, затем после изменения отправлять сообщение (PostMessage) другому потоку с индексом измененного элемента (через wParam\LParam).
А второй поток будет читать по полученному индексу с того же массива, в таком случае нужна синхронизация?

← →
Кто б сомневался © (2014-11-24 14:13) [10]

Массив стандартный делфийский, менять к примеру нужно пару байт.

← →
Mystic © (2014-11-24 14:27) [11]

> Если один поток будет менять что-то в массиве, затем после
> изменения отправлять сообщение (PostMessage) другому потоку
> с индексом измененного элемента (через wParam\LParam).

Зависит от проца. Если брать архитектуру x86 (x64), то там кэши когерентны. Т. е. ситуация, когда процессор считает старые данные невозможна. На архитектуре AMD это делается при помощи MOESI алгоритма.

https://ru.wikipedia.org/wiki/MOESI
https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%B3%D0%B5%D1%80%D0%B5%D0%BD%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%BA%D1%8D%D1%88%D0%B0

Краем уха слышал, что на ARM это немного не так. Но там есть отдельные команды, для сбрасывания кэша. И в таких случаях надо обозначать массив как volatile плюс, возможно, специальный API для установки барьеров.

← →
MBo © (2014-11-24 14:54) [12]

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

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

← →
Владислав © (2014-11-24 15:08) [13]

Кто б сомневался © (24.11.14 13:59) [9]
Если один поток будет менять что-то в массиве, затем после изменения отправлять сообщение (PostMessage) другому потоку с индексом измененного элемента (через wParam\LParam).
А второй поток будет читать по полученному индексу с того же массива, в таком случае нужна синхронизация?

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

← →
Кто б сомневался © (2014-11-24 15:15) [14]

Спасибо за инфу.

> Пока postmessage дойдет, первый опять может захотеть что-
> то менять прямо в момент чтения.

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

А поток который читает не будет читать то что ниже индекса, который пришел с PostMessage.

← →
MBo © (2014-11-24 15:40) [15]

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

← →
Inovet © (2014-11-24 16:17) [16]

> [1] MBo © (24.11.14 05:56)
> Но ведь кто-то же в неё все-таки пишет, иначе не было бы
> смысла читать да читать?

Пишет какой-нибудь контроллер.

← →
junglecat © (2014-11-24 16:28) [17]

или контролёр

← →
han_malign © (2014-11-24 16:39) [18]

> Зависит от проца. Если брать архитектуру x86 (x64), то там кэши когерентны. Т. е. ситуация, когда процессор считает старые данные невозможна.

http://www.1024cores.net/home/in-russian/barery-pamati
- в конце статьи ссылка на пример...

← →
Mystic © (2014-11-25 00:03) [19]

> - в конце статьи ссылка на пример...

Это достаточно тонкий момент. Стандарт языка С ничего не знает про конвейеры. Зато достаточно четко регламентирует поведение volatile-переменных. Очень может быть, что такое поведение нарушает стандарт. Теоретически, компилятор вполне может определять такие ситуации, и вставлять барьеры автоматически.

А ты правда этот вопрос задаешь?

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

> Ellisium © (25.11.14 09:17) [21]
>
> А ты правда этот вопрос задаешь?
>
> Ты же отлично знаешь дельфи, какие-то детские вопросы...
>

Я уже давно не стесняюсь задавать любые вопросы, если не уверен в чем-то.
А раньше думал, если задаешь простые, "всем известные" вопросы, значит ты выглядишь глупее перед всеми (не умнее, не мудрее) чем если делаешь вид что 100% в курсе.

Оказалось, что это не так ;)

Вот у ИШ подобная фобия развита, имхо (да не приемли имя его в всуе, поэтому сокращенно :)

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

- на текущий момент барьеры для volatile вставляет Java(http://habrahabr.ru/post/133981/), и "управляемые"(.NET) компиляторы(в т.ч. С++ CLR; http://msdn.microsoft.com/ru-ru/library/12a04hfd.aspx)...
Для "неуправляемого" С++ - volatile - по умолчанию означает исключительно барьер компилятора(не переупорядочивает и не кэширует в регистре).
Для межпотокового взаимодействия в "неуправляемом" С++ - согласно стандарту(С++0x) - следует использовать std::atomic<>.

x86 в этом плане - самый простой, т.к. единственный(до недавнего времени) доступный барьер - полный на запись - с блокировкой шины LOCK#(т.н. interlocked операции)...

Но, по слухам, появились инструкции - mfence, sfence, lfence
http://preshing.com/20120515/memory-reordering-caught-in-the-act/
- правда в коде генерируемом MS C++ (std::atomic) - я их не наблюдал(видимо по соображениям совместимости)...

> Кто б сомневался © (25.11.14 14:05) [23]
> Вот у ИШ подобная фобия развита, имхо (да не приемли имя
> его в всуе, поэтому сокращенно :)

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

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

Это достаточно подробно описано в технических овервью как в самом MSDN, так и в MSDN Magazine

ну собственно даже из названия MultiReadExclusiveWrite эта концепция понятна

> инструкции - mfence, sfence, lfence

- вот почему их практически никто не использует:
https://software.intel.com/en-us/forums/topic/304284
Dmitry Vyukov Tue, 11/17/2009 - 11:03
...
SFENCE is of any use ONLY if you use non-temporal store instructions (e.g. MOVNTI).
And LFENCE is completely useless, it"s basically a no-op.

MFENCE of any use ONLY is you are trying to order critical store-load sequence.
...

Нужна ли синхронизация когда потоки только читают? Найти похожие ветки