Почему «атомарный» является квалификатором @property по умолчанию в Objective C, когда я нахожусь в 100% случаев без использования атома?

Question

За несколько лет работы разработчиком для iOS я не думаю, что когда-либо использовал atomic в свойстве.Если я увижу потенциальные условия состязания или проблемы целостности данных из-за многопоточности, использование atomic для @ property не поможет.Я использую обычные методы обеспечения безопасности потоков транзакций / единиц работы (используя механизмы блокировки, семафоры и т. Д.).

Есть ли у кого-либо (или известны) какие-либо практические примеры, где atomic используемый?(Я хотел бы увидеть некоторые реальные / практические примеры кода)

После написания неатома , возможно, в миллиардный раз, мне также интересно, почему Apple решила сделать атомарным по умолчанию.

Answer 1

Что касается первой проблемы, с которой вы столкнулись, возможно, это из-за

Хотя «атомарный» означает, что доступ к свойству является потокобезопасным, простое превращение всех свойств в ваш класс в атомарный не означает, что ваш класс или, в более общем смысле, ваш объектный граф «потокобезопасен» - безопасность нитей выразить невозможно на уровне отдельных методов доступа.

Что касается того, почему Apple делает его атомарным по умолчанию, я не думаю, что есть какая-то веская причина, это было просто плохое дизайнерское решение. Ребята на сессиях WWDC неоднократно призывали людей использовать неатомные везде, где вы можете, чтобы устранить влияние на производительность.

Answer 2

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

У меня нет никаких доказательств того, что это было обоснованиемза решение, но оно имеет смысл для меня.

(Если вам интересно, в сборщике мусора все еще есть случаи, когда простое присваивание неатомично - это происходит, когда значение больше, чем размер словаНа практике это происходит только со структурами.)

Редактировать: Добавлены источники

Более подробную информацию об атомарности синтезированных свойств при сборке мусора можно найти в Язык программирования Objective-C -> Объявленные свойства -> Производительность и многопоточность , где говорится: «В среде с сборкой мусора большинство синтезированных методов являются атомарными, не вызывая таких издержек».Присущая атомарность более подробно упоминается в сессии 420 WWDC 2008 «Использование сбора мусора с Objective-C», около 29-минутной отметки.

Answer 3

В двух словах - безопасность ниток. Большинство приложений, которые мы пишем на регулярной основе, довольно просты и, как таковые, действительно выиграют от отсутствия дополнительных блокировок.

---

От Apple Язык программирования Objective-C :

Свойства являются атомарными по умолчанию, так что синтезированные методы доступа обеспечивают надежный доступ к свойствам в многопоточной среде, то есть значение, возвращаемое из метода получения или устанавливаемое через установщик, всегда полностью извлекается или устанавливается независимо от того, какие другие потоки являются выполняется одновременно. Подробнее см. « Производительность и многопоточность .»

Если вы не укажете неатомарное, то в среде с подсчетом ссылок синтезированный метод доступа get для свойства объекта использует блокировку, сохраняет и автоматически высвобождает возвращаемое значение - реализация будет похожа на следующую:

[_internal lock]; // lock using an object-level lock
id result = [[value retain] autorelease];
[_internal unlock];
return result;

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

Answer 4

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

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

-(MyObj*) someProperty
{
     return [[someInstVar retain] autorelease];
}

, поскольку какой-то другой поток может освободить someInstVar непосредственно перед увеличением счетчика хранения.

Единственный способ безопасно вернуть указатель в многопоточной среде - это нечтонапример:

-(MyObj*) someProperty
{
     @synchronized(self)
     {
         return [[someInstVar retain] autorelease];
     }
}

, а также для синхронизации сеттера.

Однако проблема в том, что блокировка очень дорога (в действительности они использовали что-то намного более легкое, чем @synchronized).но это все еще дорого), так что все в любом случае использовали неатомные и просто сделать все свойства атомарными, в общем, не обеспечивает безопасности потоков, поэтому в любом случае требуются другие методы, и они имеют тенденцию устранять проблему, которую я обсуждал выше.

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

Answer 5

Атомные вызовы - это вызовы, которые нельзя прервать. Весь вызов должен быть выполнен.

Обновление чего-то вроде переменной общего счетчика может быть атомарным, поскольку вам не нужно, чтобы два процесса пытались получить доступ к переменной одновременно. Действия должны быть выполнены «атомарно».

В этом посте SO содержится много полезной информации: Атомные и неатомарные свойства относительно различий и проблем безопасности потоков атомарных и неатомных.