Почему Cocoa свойства IBOutlet атомарны по умолчанию, а Cocoa Touch - нет?
Если вы перетащите новую розетку из интерфейса Builder в файл интерфейса (заголовка), Xcode 4.6 автоматически создаст для вас свойство...
В iOS (Cocoa Touch) он будет выглядеть следующим образом:
@property (weak, nonatomic) SomeClass *someProperty; //nonatomic accessors
В то время как на OS X (Cocoa) это будет выглядеть так:
@property (weak) SomeClass *someProperty; //atomic accessors (implicitly)
Почему?
EDIT: я не спрашиваю, что атом делает или не делает, я хорошо знаю директиву синхронизации и базовый мьютекс (или блокировку или что-то еще), что гарантирует атомарность сеттер и геттер. Я знаю, что на iOS аксессоры неатомичны, потому что UIKit не является потокобезопасным, и поэтому нет ничего, что можно было бы сделать, сделав их атомарными, это просто потеря времени процессора и времени автономной работы. Я говорю о случае по умолчанию здесь, программисты, которые знают, что они делают, будут знать, когда им нужно сделать их аксессуры атомарными.
Итак, я спрашиваю, почему они по умолчанию являются атомами по OS X. У меня создалось впечатление, что Appkit также не был потокобезопасным. И наличие атомных аксессуаров не гарантирует безопасность потоков, я даже зашел так далеко, чтобы сказать, что это идет наоборот, потому что это может дать иллюзию безопасности потоков начинающим программистам и затруднить отслеживание ошибок в параллельных приложениях, откладывая сбои к более позднему времени и тем самым сделать их труднее проследить. И только потому, что настольные компьютеры относительно мощные, не означает, что ресурсы должны быть потрачены впустую (обратите внимание, что я не говорю о преждевременной оптимизации здесь), и, поскольку разумно, что инженеры Apple являются разумными программистами, должна быть веская причина, по которой они решил, что по умолчанию свойства синтезируют атомарные аксессоры.
Ответы
Ответ 1
В этом контексте спецификатор atomic сообщает компилятору, что установщик и аксессор должны быть синтезированы, чтобы быть безопасным для вызова из нескольких потоков. Это добавляет небольшие накладные расходы, требуя, чтобы методы вынимали блокировку до того, как значение свойства может быть записано или прочитано.
Поскольку элементы пользовательского интерфейса как UIKit, так и Cocoa предназначены только для доступа из основного потока, дополнительная блокировка не нужна. Накладные расходы на создание атома атома довольно минимальны, но в более ограниченной среде iOS каждая маленькая унция скорости является ценной. Следовательно, почему iOS по умолчанию использует свойства nonatomic для IB Outlets.
Отредактировано в ответ на ваш расширенный вопрос: Я чувствую, что стоимость использования атомных свойств стоит накладных расходов на Mac. Theres аргумент, что использование атомных свойств маскирует набор ошибок и, следовательно, является плохим. Я бы сказал, что с точки зрения пользователей Apple должна устанавливать значения по умолчанию, чтобы даже плохо закодированные приложения терпели крах меньше. Это ставит бремя на продвинутых программистов, чтобы знать, когда безопасно использовать неатомические свойства в обмен на преимущества производительности.
Не слушая кого-то из команды в то время, мы можем только размышлять о своем процессе мышления, но я уверен, что это было расценено.
Ответ 2
Простой, черт возьми: атомные причины накладных расходов (незначительные на OSX) с его неявными механизмами mutex.
iOS (как встроенная система на чипе ARM) не может позволить себе это накладные расходы, следовательно, IBOutlets по умолчанию неатомичны.
Одним словом: Производительность.
Что касается того, почему они по умолчанию используют атомы в OSX, безопасность потоков в свойствах - это хорошая вещь для многопоточной многопоточной среды с множеством приложений , такой как OSX (особенно по сравнению с iOS, приложения чаще взаимодействуют друг с другом в OSX, чем в iOS).
И, как было сказано ранее, накладные расходы на OSX на самом деле незначительны, поэтому они дефолтировали его так.
Ответ 3
В этом вопросе была довольно продолжительная дискуссия об атомных и неатомных свойствах: В чем разница между атомными и неатомическими атрибутами?, и я бы сделал ставку на то, что это больше связано с относительной сложностью интерфейсов, обычно встречающихся в приложениях OSX и приложениях iOS. Достаточно часто иметь приложение OSX, работающее на нескольких потоках. Таким образом, интерфейсы могут работать чаще в многопоточной среде. В iOS, хотя приложения, безусловно, усложняются по мере созревания системы, они по-прежнему работают на гораздо более базовой ОС, которая в настоящее время выгодно относится к среде без потоков.
Также есть некоторые разговоры о неатомных свойствах, которые обычно имеют меньшие накладные расходы по сравнению с атомными, и с меньшими процессорами и меньшим объемом памяти, обычно обнаруженным в устройствах iOS, было бы разумно использовать свойства по умолчанию для неатомических операций, если не потребуются дополнительные накладные расходы.
Ответ 4
OSX может управлять несколькими потоками, и большая часть приложения использует несколько потоков. Поэтому по умолчанию установлено значение атомарное.
В то время как в случае iOS, вы редко используете несколько потоков, поэтому неатомный служит вам.
