потокобезопасный bool (?)

Является ли работа с обыкновенным bool потокобезопасной? Если нет, то можно пример, где что-то пойдет не так при работе с переменной типа bool из двух потоков?

0

Не, он, как и другие основные типы, не потокобезопасен. Пример:

0

Думается, тут путанница в терминологии

Потокобезопасность - это свойство программы, функции, куска кода, а вовсе не типа. А пример из поста #2 к потокобезопасности никакого отношения не имеет, он всего лишь демонстрирует, что операция "flag = !flag" НЕ является атомарной

Добавлено через 44 секунды
Что такое thread safe?

0

Evg, раз термин "потокобезопасный" уже занят, пусть будет "безопасный к использованию во многих потоках". К примеру, переменные типа int использовать в нескольких потоках без дополнительной заботы нельзя: если один поток начнет менять значение и второй его считает в процессе, то прочитанное значение не будет соответствовать ни тому, что было, ни тому, что стало. С переменными же типа bool такого быть не может. Вот и думаю, а что может? И если ничего, то в чем его отличие от std::atomic<bool>?

0

Это называется словом "атомарный". Т.е. любое обращение к bool'у постфактум будет атомарным, т.к. его размер равен 1 байту. Возможно, что такое требование атомарности даже в стандарте записано, но я точно не знаю

0

Evg, подозреваю что на современных процессорах все простые типы атомарны или я не прав?

0

Сообщение от vxg Evg, подозреваю что на современных процессорах все простые типы атомарны или я не прав?

Не везде. Например, на sparc v9 16-байтный long double читается/пишется двумя 8-байтными операциями. На интеле возможно, что int по НЕвыровненному адресу отработает НЕ атомарно (но надо спрашивать тех, кто в интеле разбирается). А если смотреть более узкий вариант - типы в пределах разрядности процессора по выровненным адресам - то тут постфактум скорее всего всё будет атомарно. Разумеется при условии, что компилятор не начудит и не решит разбить обращение на несколько однобайтных

1

Сообщение от Evg любое обращение к bool'у постфактум будет атомарным, т.к. его размер равен 1 байту.

атомарность буля не гарантируется.

Сообщение от LetoLetoD можно пример

http://ru.cppreference.com/w/cpp/atomic/atomic

0

hoggy, каков физический смысл отсутствия гарантии атомарности если допустить что bool представлен байтом?

0

Сообщение от vxg каков физический смысл отсутствия гарантии атомарности если допустить что bool представлен байтом?

такой же, как и для любых других не_атомарных операций.

0

hoggy, эм.. может мы о разном.. разве может машина "разорвать" байт? я уже не говорю про то что байт целиком нам не нужен - мы проверяем только ноль там или не ноль.

0

Сообщение от LetoLetoD К примеру, переменные типа int использовать в нескольких потоках без дополнительной заботы нельзя: если один поток начнет менять значение и второй его считает в процессе, то прочитанное значение не будет соответствовать ни тому, что было, ни тому, что стало.

Такое, наверное, возможно лишь на некоторых платформах с "расслабленной" моделью памяти.
На Win-платформе, например (Intel|Windows|MS C/C++), чтение и запись (но не "read-modify-update")
базовых типов, влезающих в size_t, атомарны, хотя об этом нигде не сказано в документации.
Это позволяет в ряде случаев обходиться без mutex, atomic, fence и т.п. и получать на выходе
более эффективный, но при этом корректный с точки зрения синхронизации машинный код.

С переменными же типа bool такого быть не может. Вот и думаю, а что может? И если ничего, то в чем его отличие от std::atomic<bool>?

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

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

1. Атомарность доступа (atomicity).

2. Видимость изменений (visibility).

3. Порядок доступа к памяти (memory order).

С 1 и 2 все должно быть понятно. В п.3 нам нужна гарантия, что флаг взводится в true строго
после того, как некие данные были подготовлены. Например, если у тебя есть какой-то другой bool,
являющийся частью данных, то компилятор или процессор может перемешать запись в эти bool-ы и
в результате ждущий поток начнет работать с данными еще до того, как они были подготовлены.
Поэтому в п.3. нужен "барьер" (memory barrier, memory fence). Барьер гарантирует, например,
что запись в A будет выполнена строго после записи в Б.

Все эти три пункта и обеспечиваются atomic.

Сообщение от Evg На интеле возможно, что int по НЕ выровненному адресу отработает НЕ атомарно

Отработает тоже атомарно, но лишь при условии, что int целиком находится внутри одной линейки кэша.

10

Убежденный, вот про фокус с пребыванием значений в промежуточных звеньях я как раз забыл, спасибо!

0

Сообщение от Убежденный Такое, наверное, возможно лишь на некоторых платформах с "расслабленной" моделью памяти. На Win-платформе, например (Intel|Windows|MS C/C++), чтение и запись (но не "read-modify-update") базовых типов, влезающих в size_t, атомарны, хотя об этом нигде не сказано в документации. Это позволяет в ряде случаев обходиться без mutex, atomic, fence и т.п. и получать на выходе более эффективный, но при этом корректный с точки зрения синхронизации машинный код.

Здесь мы уже переходим с уровня "атомарность" на уровень "синхронизация". Атомарность обращения в память является необходимым условием для построения такой расслабленной синхронизации, но не является достаточным условием. Чтобы такая схема работала, нужна ещё и поддержка memory ordering в аппаратуре (в контроллере памяти). Конкретно у intel'овского контроллера памяти есть следующее правило (на него многие закладываются, но далеко не все знают, в каком именно варианте оно работает в аппаратуре). Если мы в контроллере памяти имеем последовательность операций обращения в память (в общем случае пришедшую с различных процессоров/ядер):

аппаратура гарантирует, что если "load B" прочитал "новое" значение, которое было записано в "store B" (т.е. значение успело пройти через все стадии синхронизации кэшей), то "load A" гарантированно прочитает "новое" значение, которое было записано в "store A" (с учётом всех синхронизаций кэшей и возможных переупорядочиваний обращений в аппаратуре)

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

Собственно, это до сих пор служит проблемой, когда софт, который годами работал на intel'е, вдруг перестаёт работать при переносе на другую платформу. Поэтому этой особенностью нужно пользоваться только тогда, когда есть 100% уверенность, что программа будет работать только на intel'е. На всякий случай: под intel'ом я подразумеваю процессоры с intel'овской системой команд (т.е. включая AMD и какие-нибудь другие возможно существующие процессоры с intel'овской системой команд)

Добавлено через 59 секунд

Сообщение от Убежденный Отработает тоже атомарно, но лишь при условии, что int целиком находится внутри одной линейки кэша

Т.е. получается, что обращение к int'у (точнее, к любому типу размером более 1 байта) НЕ является гарантированно атомарным

3

Сообщение от Evg Конкретно у intel'овского контроллера памяти есть следующее правило (на него многие закладываются, но далеко не все знают, в каком именно варианте оно работает в аппаратуре). Если мы в контроллере памяти имеем последовательность операций обращения в память (в общем случае пришедшую с различных процессоров/ядер): Code 1 2 3 4 store A (запись значения) store B (запись guard'а) load B (чтение guard'а) load A (чтение значения) аппаратура гарантирует, что если "load B" прочитал "новое" значение, которое было записано в "store B" (т.е. значение успело пройти через все стадии синхронизации кэшей), то "load A" гарантированно прочитает "новое" значение, которое было записано в "store A" (с учётом всех синхронизаций кэшей и возможных переупорядочиваний обращений в аппаратуре)

Насколько мне известно (из мануалов, больше неоткуда), такое поведение у Intel еще со
времен 486/P6: "reads are not reordered with other reads, writes are not reordered with older reads,
writes are not reordered with other writes (with the exceptions ...)" и т.д.
Т.е. load A не может "перепрыгнуть" через load B, также как store B - через store A.

Поэтому на x86/x64 барьеры в примере с "data ready", который я описывал выше, нужны
только для форсирования порядка на уровне компилятора, а архитектура все сделает сама.

Поэтому этой особенностью нужно пользоваться только тогда, когда есть 100% уверенность, что программа будет работать только на intel'е.

Да, полностью согласен.

1

Сообщение от Убежденный На Win-платформе, например (Intel|Windows|MS C/C++), чтение и запись (но не "read-modify-update") базовых типов, влезающих в size_t, атомарны, хотя об этом нигде не сказано в документации. Это позволяет в ряде случаев обходиться без mutex, atomic, fence и т.п. и получать на выходе более эффективный, но при этом корректный с точки зрения синхронизации машинный код.

Добавлю, что "read-modify-update" инструкция будет атомарна на однопроцессорной машине.

На счет документации. Вот что нашел в манах:

Intel64 and IA-32 Architectures Software Developer’s Manual, Volume 3A (Chapter 8, “Multiple-Processor Management”)

8.1.1 Guaranteed Atomic Operations The Intel486 processor (and newer processors since) guarantees that the following basic memory operations will always be carried out atomically: • Reading or writing a byte • Reading or writing a word aligned on a 16-bit boundary • Reading or writing a doubleword aligned on a 32-bit boundary The Pentium processor (and newer processors since) guarantees that the following additional memory operations will always be carried out atomically: • Reading or writing a quadword aligned on a 64-bit boundary • 16-bit accesses to uncached memory locations that fit within a 32-bit data bus The P6 family processors (and newer processors since) guarantee that the following additional memory operation will always be carried out atomically: • Unaligned 16-, 32-, and 64-bit accesses to cached memory that fit within a cache line

0

jupman, под документацией подразумевался C++, а не Intel или машинные коды.
А с этой точки зрения компилятор может реализовать '++val' как 'mov, add, mov', что не атомарно.

0

Сообщение от jupman Добавлю, что "read-modify-update" инструкция будет атомарна на однопроцессорной машине

Это как это так? Процессор отработал read, далее пришло прерывание, переключение задачи, другая задача испортила память, потом вернулись к основной задаче и она исполнила modify-update со старым (неактуальным) значением, прочтённым до прерывания

0

Evg, к примеру возьмем команду inc dword ptr [mem], на многопроцессорной машине она не атомарна. Дело в том, что такие команды делятся на микроопирации read-modify-update. К примеру между read и update одного процессора может пролезть read-modify-update другого процессора. Что-бы избежать данной проблемы используется префикс LOCK. На однопроцессорной машине такая команда атомарна.

Добавлено через 3 минуты
Evg, всякие там WinAPI InterlockedIncrement etc, это обертки над инструкциями с LOCK префиксами.

Добавлено через 3 минуты

Сообщение от Evg Процессор отработал read, далее пришло прерывание, переключение задачи, другая задача испортила память, потом вернулись к основной задаче и она исполнила modify-update со старым (неактуальным) значением, прочтённым до прерывания

Такое возможно если компилятор оптимизирует обращение к переменной 'mov, add, mov' (как уже сказал Убежденный). От этого спасает volatile.

0

Сообщение от jupman Evg, к примеру возьмем команду inc dword ptr [mem]

А... ты про такое...
Ну всё равно в наши дни уже малоактуально, т.к. одноядерные системы ещё поискать надо

0