ИП
А , ну ок
Size: a a a
2020 December 06
RP
Вроде можно обернуть в volatile_read, но я не помню с какого стандарта
что не сделает код потокобезопасным. об этом говорили уже миллион раз
AM
Использовать раст (простите)
а разве раст не оптимизирует тут так же?
RP
а разве раст не оптимизирует тут так же?
Он просто не даст использовать структуру из другого потока без примитивов синхронизации (без него будет ошибка компиляции).
N
что не сделает код потокобезопасным. об этом говорили уже миллион раз
А кто говорит про потокобезопасность, только про убирание оптимизации :)
RP
А кто говорит про потокобезопасность, только про убирание оптимизации :)
вот это подстава, конечно.
N
вот это подстава, конечно.
Нет, это ответ, вопрос был про оптимизации. Вдруг так всего 1 одно ядро и вечно свитчается контектст исполнения
VS
А кто говорит про потокобезопасность, только про убирание оптимизации :)
оптимизации возможны лишь в отсутствие гарантированного наблюдаемого поведения. нужно устранить причину, а не бороться с последствиями
N
оптимизации возможны лишь в отсутствие гарантированного наблюдаемого поведения. нужно устранить причину, а не бороться с последствиями
Это уже оффтоп
A
оно нормально синхронизировано. но я опасаюсь, что возможна оптимизация и size() будет вычислен только один раз
A
а нужно обработать и добавленные во время ожидания элементы
RP
да, поэтому и надо size() получать за мьютексом.
d
Alexey
вот это вряд-ли. Какая разница как именно ждёт. Если что, то это действительно wait от condition_variable
Думаю тут прокатит, вроде как wait расставляют барьеры памяти, но это надо уточнять
RP
Alexey
Всем привет. вот и у меня появился вопрос для сообщества
Есть такой цикл:
Есть такой цикл:
auto &ref = <some vector>Тут ведь нельзя быть уверенным, что в условии цикла ref.size() не будет закеширован оптимизатором и добавленные элементы в цикле обработаются?
for (size_t pos = 0; pos < ref.size(); pos++) {
. . .
wait(); //тут текущий поток находится в ожидании, при этом в вектор ref могут добавиться элементы
}
Почитай https://vorbrodt.blog/2019/02/21/memory-barriers-and-thread-synchronization/ , только там в последнем примере УБ. Но идея должна быть ясна
A
ок, спасибо, посмотрю
d
Он просто не даст использовать структуру из другого потока без примитивов синхронизации (без него будет ошибка компиляции).
Не даст даже если по логике у меня потоки одновременно не лезут в одну память, а явной синхронизации нет?
RP
Не даст даже если по логике у меня потоки одновременно не лезут в одну память, а явной синхронизации нет?
даст, если использовать scoped threads