Летучие против памяти заборы

Приведенный ниже код используется для назначения работы нескольким потокам, их пробуждения и ожидания завершения. «Работа» в этом случае состоит из «очистки объема». Что именно делает эта операция, не имеет значения для этого вопроса — она ​​просто помогает в контексте. Код является частью огромной системы обработки транзакций.

void bf_tree_cleaner::force_all()
{
for (int i = 0; i < vol_m::MAX_VOLS; i++) {
_requested_volumes[i] = true;
}
// fence here (seq_cst)

wakeup_cleaners();

while (true) {
usleep(10000); // 10 ms

bool remains = false;
for (int vol = 0; vol < vol_m::MAX_VOLS; ++vol) {
// fence here (seq_cst)
if (_requested_volumes[vol]) {
remains = true;
break;
}
}
if (!remains) {
break;
}
}
}

Значение в логическом массиве _requested_volumes[i] говорит ли нить i есть работа, чтобы сделать. Когда это сделано, рабочий поток устанавливает значение false и возвращается в спящий режим.

У меня проблема в том, что компилятор генерирует бесконечный цикл, где переменная remains всегда true, хотя все значения в массиве были установлены в false. Это происходит только с -O3,

Я пробовал два решения, чтобы исправить это:

1. декларировать _requested_volumes летучий
   (РЕДАКТИРОВАТЬ: это решение действительно работает на самом деле. См редактировать ниже)

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

2. Ввести заборы памяти

Метод wakeup_cleaners() приобретает pthread_mutex_t внутренне для того, чтобы установить флаг пробуждения в рабочих потоках, чтобы он неявно создавал надлежащие ограждения памяти. Но я не уверен, влияют ли эти заборы на доступ к памяти в методе вызывающей стороны (force_all()). Поэтому я вручную ввел заборы в местах, указанных в комментариях выше. Это должно убедиться, что записи выполняются рабочим потоком в _requested_volumes видны в основной теме.

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

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

РЕДАКТИРОВАТЬ: Мои предположения были неверны, и решение 1 на самом деле делает Работа. Тем не менее, мой вопрос остается для того, чтобы уточнить использование энергозависимых и памяти заборов. Если volatile — такая плохая вещь, которая никогда не должна использоваться в многопоточном программировании, что еще я должен использовать здесь? Влияет ли ограничение памяти на оптимизацию компилятора? Потому что я рассматриваю их как две ортогональные проблемы и, следовательно, ортогональные решения: ограждения для видимости в нескольких потоках и изменчивые для предотвращения оптимизации.