LINUX.ORG.RU

Обращения на чтение при многопоточности, требуется ли блокировать?

 , ,


1

3

Требуется ли производить блокировки в многопоточной программе при обращении к ячейке памяти, если операции только на чтение? Запись производиться не будет, переменная изначально инициализируется и после не меняется. Программа компилится под разное железо, в том числе на ARM4.

Перемещено tailgunner из general

Если значение переменной не изменяется, то есть это константа, то зачем? // Но я не спец в С++, только начал постигать.

dnb ★★★★
()
Ответ на: комментарий от dnb

Если значение переменной не изменяется, то есть это константа, то зачем?

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

vividhamster
() автор топика
Ответ на: комментарий от vividhamster

Константа это то, что вкомпилено в код, т.е. прямо в параметры процессорной команды, и обращений к памяти не происходит вообще

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

P. S.: А вот чтобы до завершения инициализации к объекту никто не обращался, следить нужно. Впрочем, это в любом случае UB

Deleted
()

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

pon4ik ★★★★★
()
Ответ на: комментарий от vividhamster

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

dnb ★★★★
()

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

SR_team ★★★★★
()
Ответ на: комментарий от SR_team

Ну скорее не для счётчика а для всех ассоциативных и коммутативныж операций. Но в аппаратуре обвчно реализовано только для add/sub

lberserq
()

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

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 1)
Ответ на: комментарий от vividhamster

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

trex6 ★★★★★
()
Ответ на: комментарий от anonymous

Поди объясни это ценителям )

Deleted
()
Ответ на: комментарий от Deleted

Кто вам такую ерунду сказал?

Код на Vala:

const int tmp_var1 = 1;
const int tmp_var2 = 2;
int summ = 0;
summ = tmp_var1 + tmp_var2;
транслируется в код на Си:
#define tmp_var1 1
#define tmp_var2 2
gint summ = 0;
summ = tmp_var1 + tmp_var2;
т.е. как сказал vividhamster — «Константа это то, что вкомпилено в код».

anonymous
()
Ответ на: комментарий от anonymous

Плохой, негодный пример) Машкод в студию. И в качестве константы взять тип, отличный от скалярного

Deleted
()
Ответ на: комментарий от anonymous

Соглсен, но если человек просто спрашивает про блокировки, пусть начнет с блокировок. После этого сам дорастет до concurrency in action.

trex6 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.