Mutex и read-only переменные

Нет. Зачем он может понадобиться?

Нужен ли мьютекс для ro доступа к переменным типа bool, int?

Если ты можешь обеспечить однократность чтения области (memory barrier, volatile) - нет.

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

Если их может менять другой поток - да. И от типа тут ничего не зависит, если только это не atomic.

Ну, как ты заметил выше, есть volatile.

Он работает крайне плохо на не-x86.

volatile не обеспечивает атомарность.

за что тебе зарплату платят вообще :D

volatile не обеспечивает атомарность.

#define __ACCESS_ONCE(x) ({ \
	 __maybe_unused typeof(x) __var = (__force typeof(x)) 0; \
	(volatile typeof(x) *)&(x); })
#define ACCESS_ONCE(x) (*__ACCESS_ONCE(x))


/**
 * atomic_read - read atomic variable
 * @v: pointer of type atomic_t
 *
 * Atomically reads the value of @v.
 */
static __always_inline int atomic_read(const atomic_t *v)
{
	return ACCESS_ONCE((v)->counter);
}

Это тебе из сырцов лялеха для x86 :)

Между atomic_t и int разницу не видишь?

Между atomic_t и int разницу не видишь?

Ну ты в курсе, что atomic_t это структура с единственным полем - int val?

Наводящий вопрос: на каких платформах?

Mutex и read-only переменные
Нужен ли мьютекс для ro доступа к переменным типа bool, int?

Это константы имеются в виду или какого рода read-only переменные? Это вопрос об атомарности операций чтения и о кэшировании или о чем?

На всех :) См. include/linux/types.h.

А вот ACCESS_ONCE() на всех платформах разный. Потому что volatile за пределами x86 нужных результатов не дает.

http://www.makelinux.net/books/lkd2/ch09lev1sec1

Да, я это читал. На что ты хочешь указать?

volatile везде даёт нужные результаты - не даёт оптимизатору удалить чтение из памяти. А атомарности, как я уже сказал, он не даёт нигде. Поэтому и разный.

volatile везде даёт нужные результаты - не даёт оптимизатору удалить чтение из памяти. А атомарности, как я уже сказал, он не даёт нигде. Поэтому и разный.

В случае с x86 его достаточно для ACCESS_ONCE(), через который реализуются атомарные операции. Я слегка не понимаю, о чем мы тут спорим.

atomic нужен

s/атомарные операции/атомарные операции чтения/

При чём тут x86? Где-то было сказано что речь идёт о конкретной платформе?

Ну... Я сказал, что речь идет о конкретной платформе. На x86 достаточно volatile, на не-x86 - нет. Прочитай тред сначала уже.

Читать на что отвечаете следовало бы вам, ибо на замечание о неатомарности вы зачем-то постите платформенно-специфичный код.

Читать на что отвечаете следовало бы вам, ибо на замечание о неатомарности вы зачем-то постите платформенно-специфичный код.

неатомарности

Я запостил платформенно-специфичный код атомарной операции чтения :)

барьеры с std::memory_model_consume/std::memory_model_release или как-то так

Если никто их не модифицирует, то не нужен. Если модифицирует, то нужно синхронизировать доступ(атомики, как вариант).

Надо.

На всех, о которых стоит говорить.

за что тебе зарплату платят вообще :D

За работу же, ну )

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

Почему с разными, если там read-only?

Зачем? read-only данные же. immutable считай

Если их может менять другой поток - да.

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

Если не важно, не читай его.

Если оно используется как граничное значение для какого-то цикла - нужна блокировка либо сохрани в локальную переменную

Если оно используется как граничное значение для какого-то цикла

Нет, не используется

за что тебе зарплату платят вообще :D

Значит сохрани в локалькую переменную либо читай в самый последний момент

Твой работодатель не видел ни одного твоего треда? Ему было бы полезно понять что за херня в его бизнесе.

Можешь ему ссылку скинуть. Если тебе так хочется

Почему с разными, если там read-only?

Предполагается, что в эту переменную кто-то пишет. Иначе зачем её читать, если значение и так известно заранее?

Иначе зачем её читать, если значение и так известно заранее?

Почему заранее? Кто-то может ее в рантайме задавать. А потом кто-то будет ее читать. Можно делать достаточно сложные и полезные immutable структуры данных.

Предполагается, что в эту переменную кто-то пишет. Иначе зачем её читать, если значение и так известно заранее?

А ты как argc/argv читаешь? Или считаешь, что их значение и так известно заранее?

А ты как argc/argv читаешь? Или считаешь, что их значение и так известно заранее?

У тебя хобби такое - в каждом треде заново argc/argv читать? :D

У тебя хобби такое - в каждом треде заново argc/argv читать? :D

А у тебя? Это же ты не знаешь, что данные можно сначала подготовить, а потом вычисления для них запустить.