list :: empty () многопоточное поведение?

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

Это нормально, если вызов list::empty()100% времени неправильный. Я только хочу , чтобы избежать сбоя или нарушений одновременно list::push()и list::pop()вызовов.

Могу ли я предположить, что VC ++ и Gnu GCC только иногда empty()ошибаются и ничего хуже?

if(list.empty() == false){ // unprotected by mutex, okay if incorrect sometimes
    mutex.lock();
    if(list.empty() == false){ // check again while locked to be certain
         element = list.back();
         list.pop_back();
    }
    mutex.unlock();
}

Это нормально, если вызов list::empty()100% времени неправильный.

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

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

Существует чтение и запись (скорее всего, для sizeчлена std::list, если мы предположим, что он назван так), которые не синхронизированы друг с другом . Представьте, что один поток вызывает empty()(в вашем внешнем if()), в то время как другой поток входит во внутренний if()и выполняет pop_back(). Затем вы читаете переменную, которая, возможно, изменяется. Это неопределенное поведение.

В качестве примера того, как все может пойти не так:

Достаточно умный компилятор мог видеть, что mutex.lock()не может изменить list.empty()возвращаемое значение и, таким образом, полностью пропустить внутреннюю ifпроверку, что в конечном итоге привело к появлению pop_backв списке, в котором последний элемент был удален после первого if.

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

Это только одна из нескольких оптимизаций (или поведения оборудования), которые могут сломать ваш код.