Другими словами, запись и чтение самого свойства atomic фактически является «поточно-ориентированным» (защищенным от повреждения несколькими авторами), но, конечно, эта защита не распространяется на более широкие возможности. логика.
- Это точное понимание?
Во многом да.
Я бы не стал использовать термин «потокобезопасный» в этом контексте, тем не менее, особенно в контексте объектов, поскольку представление о том, что указатель не поврежден, далеко от любого практического смысла потокабезопасность самого объекта, тем более более широкая логика приложения.
При каких обстоятельствах атомное свойство действительно полезно? Я мог бы придумать несколько простых примеров, когда свойство - это своего рода счетчик или изменяющийся объект, который не должен отражать текущее состояние и т. Д., Но они кажутся необычными по сравнению с многопоточными сценариями, где вам действительно нужна явная блокировка доступа - в которыхВ этом случае вы могли бы просто использовать неатомическое для фактического свойства все время.
Они могут быть полезны при работе с примитивными типами данных в определенных сценариях (например, свойство логического состояния, обозначающее, является ли какой-либо фоновым)процесс закончен). Они также могут быть полезны в особых случаях, когда вы имеете дело с неизменяемыми объектами без состояния.
Но в большинстве многопоточных сценариев свойства atomic обычно не обеспечивают безопасность потоков.
Почему именно люди постоянно говорят, что атомарность не «гарантирует безопасность потоков»? Это кажется верным только в том случае, если NSLock не гарантирует безопасность потока или синхронизированный не гарантирует безопасность потока - предупреждение для непосвященных? В противном случае это кажется запутанным обозначением, поскольку сам смысл этих механизмов синхронизации заключается в том, что они предназначены для использования в поточно-ориентированном проектировании и, как известно, надежны в своей проектной работе.
Мы делаемэто потому, что были люди (например, https://stackoverflow.com/a/17571453/1271826), которые ошибочно полагают, что свойства atomic обеспечивают безопасность потоков, когда это почти всегда не удается сделать. В свое время казалось, что когда-то задают вопрос о безопасности потоковкто-то мог бы присоединиться к «о, используйте atomic свойства». Казалось, что существует постоянное смешение «безопасности потоков» и скромной защиты от коррупции, которую предлагает atomic.
Итак, да,«Не имеет ничего общего с безопасностью потоков» является немного сильным, но в подавляющем большинстве случаев атомарные свойства не могут обеспечить безопасность потоков и при наличии правильно реализованной синхронизации (такой как блокировки, @synchronized, GCD и т. Д. .), просто введите ненужные накладные расходы.
Это оченьесли нет других механизмов синхронизации (таких как блокировки и т. д.). При правильной реализации этих механизмов всегда можно добиться безопасности потока. Но во многих случаях (в большинстве случаев?) atomic просто не сработает. Конечно, atomic может смягчить один очень узкий тип искажения значений / указателей, но это, как правило, не делает поток кода безопасным.