Нужен ли мне семафор при чтении из глобальной структуры?

Если все потоки только читают, вам не нужен семафор.

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

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

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

Нет.

Как правило, вам нужны семафоры для предотвращения одновременного доступа к ресурсам (в данном случае это int). Однако, поскольку член read_only доступен только для чтения, он не будет меняться между / во время доступа. Обратите внимание, что это даже не обязательно атомарное чтение - если ничего не изменится, вы всегда в безопасности.

Как вы изначально устанавливаете read_only?

Добавление к предыдущим ответам:

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

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

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

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

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

Пример: - поток обновляет элементы «день», «месяц» и «год» в структуре. Это должно происходить атомарно, чтобы другой поток не прочитал структуру после приращения «месяца», но до того, как «день» перейдет в 1, чтобы избежать таких дат, как 31 февраля. Обратите внимание, что вы должны честь мьютекса при чтении; в противном случае вы можете прочитать ошибочное наполовину обновленное значение.

Читателям тоже нужны мьютексы!

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

Вот почему, в виде примера.

Представьте себе часы, которые обновляются каждую секунду с помощью кода:

if (++seconds > 59) {        // Was the time hh:mm:59?
   seconds = 0;              // Wrap seconds..
   if (++minutes > 59)  {    // ..and increment minutes.  Was it hh:59:59?
     minutes = 0;            // Wrap minutes..
     if (++hours > 23)       // ..and increment hours.  Was it 23:59:59?
        hours = 0;           // Wrap hours.
    }
}

Если код не защищен мьютексом, другой поток может читать переменные hours, minutes и seconds во время обновления. Следуя приведенному выше коду:

[Start just before midnight] 23:59:59
[WRITER increments seconds]  23:59:60
[WRITER wraps seconds]       23:59:00
[WRITER increments minutes]  23:60:00
[WRITER wraps minutes]       23:00:00
[WRITER increments hours]    24:00:00
[WRITER wraps hours]         00:00:00

Время недействительно с первого приращения до последней операции шесть шагов спустя. Если читатель проверит часы в течение этого периода, он увидит не только неправильное значение, но и значение незаконный. И поскольку ваш код, скорее всего, будет зависеть на часах без отображение времени напрямую, это классический источник ошибок «рикошета», которые, как известно, трудно отследить.

Исправить это просто.

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

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

Большое спасибо всем замечательным ответчикам (и за все прекрасные ответы).

Подводить итоги:

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

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