objective c - objective - ¿Por qué las propiedades de IBOutlet de Cocoa son atómicas por defecto y las de Cocoa Touch no lo son?
xcode manual pdf (4)
Si arrastra una nueva salida de Interface Builder a un archivo de interfaz (encabezado), Xcode 4.6 creará automáticamente una propiedad para usted ...
En iOS (Cocoa Touch) se verá así:
@property (weak, nonatomic) SomeClass *someProperty; //nonatomic accessors
Mientras que en OS X (Cocoa) se verá así:
@property (weak) SomeClass *someProperty; //atomic accessors (implicitly)
¿Por qué?
EDITAR : No pregunto qué hace el atómico o qué no lo hace, soy muy consciente de la directiva de sincronización y del mutex subyacente (o bloqueo o lo que sea) que garantiza la atomicidad del configurador y el captador. Sé que en iOS, los accesores no son atómicos porque UIKit no es seguro para subprocesos, por lo que no se gana nada al hacerlos atómicos, es solo una pérdida de tiempo del procesador y la vida útil de la batería. Estoy hablando del caso predeterminado aquí, los programadores que saben lo que están haciendo sabrán cuándo necesitan que sus accesores sean atómicos.
Así que pregunto por qué son atómicos por defecto en OS X. Tenía la impresión de que Appkit tampoco era seguro para subprocesos. Y tener accesores atómicos no garantiza la seguridad de subprocesos, incluso me atrevería a decir que va en sentido contrario, ya que puede dar la ilusión de seguridad de subprocesos a los programadores novatos y hacer más difícil el seguimiento de errores en aplicaciones concurrentes al diferir los bloqueos a un tiempo posterior y al hacerlo, haciéndolos más difíciles de rastrear. Y solo porque las computadoras de escritorio sean relativamente poderosas no significa que se deban desperdiciar recursos (tenga en cuenta que no estoy hablando de optimización prematura aquí), y como es lógico que los ingenieros de Apple sean programadores razonables, debe haber una buena razón por la que tienen Decidió hacer que las propiedades sintetizaran los accesores atómicos por defecto.
En este contexto, el especificador atomic le dice al compilador que el definidor y el descriptor de acceso deben sintetizarse para que sea seguro llamar desde múltiples subprocesos. Esto agrega una pequeña sobrecarga al requerir los métodos para eliminar un bloqueo antes de que se pueda escribir o leer un valor de propiedades.
Dado que los elementos de la interfaz de usuario de UIKit y Cocoa solo están diseñados para ser accedidos desde el hilo principal, el bloqueo adicional no es necesario. La sobrecarga de hacer una propiedad atómica es bastante mínima, pero en el entorno más restringido de iOS, cada pequeña onza de velocidad es valiosa. Por eso, iOS utiliza de manera nonatomic propiedades no nonatomic para los Outlets IB.
Editado en respuesta a su pregunta ampliada: mi opinión es que el costo de usar propiedades atómicas vale la pena en la Mac. Hay un argumento de que el uso de propiedades atómicas enmascara una colección de errores y, por lo tanto, es algo malo. Yo diría que, desde la perspectiva de los usuarios, Apple debería establecer los valores predeterminados para que incluso las aplicaciones mal codificadas se bloqueen menos. Pone en los programadores avanzados la responsabilidad de saber cuándo es seguro usar propiedades no atómicas a cambio de una ventaja de rendimiento.
Sin tener noticias de alguien en el equipo en el momento, solo podemos especular sobre su proceso de pensamiento, pero estoy seguro de que fue una decisión considerada.
Hubo un debate bastante prolongado sobre las propiedades atómicas y no atómicas en esta pregunta: ¿Cuál es la diferencia entre los atributos atómicos y no atómicos? y apostaría a que tiene más que ver con la complejidad relativa de las interfaces que generalmente se encuentran en las aplicaciones OSX en comparación con las aplicaciones de iOS. Es bastante común tener una aplicación OSX ejecutándose en múltiples hilos todo el tiempo. Por lo tanto, las interfaces se prestan para operar más comúnmente en un entorno de subprocesos múltiples. En iOS, aunque las aplicaciones están ganando complejidad a medida que el sistema madura, aún se ejecutan en un sistema operativo mucho más básico que actualmente se presta favorablemente a un entorno sin subprocesos.
También se habla de las propiedades no atómicas que generalmente tienen menos sobrecarga frente a las atómicas y con CPU más pequeñas y menos memoria en general en los dispositivos iOS, tendría sentido que las propiedades predeterminadas sean no atómicas a menos que se justifique la sobrecarga adicional.
OSX puede controlar varios subprocesos, y la mayoría de la aplicación utiliza varios subprocesos. Por lo tanto, el valor predeterminado se establece en atómico.
Mientras que en el caso de iOS, rara vez se usa para subprocesos múltiples, por lo que no es atómico.
Simple como el infierno: las causas atómicas de sobrecarga (insignificante en OSX) con sus mecanismos de exclusión mutua implícitos.
iOS (como un sistema integrado en un chip ARM) no puede permitirse esta sobrecarga, por lo tanto, los IBOutlets por omisión son no atómicos.
En una palabra: Performance .
En cuanto a la razón por la cual son predeterminados a atómicos en OSX, la seguridad de subprocesos en las propiedades es algo agradable de tener en un entorno de múltiples subprocesos masivos , como OSX (especialmente en comparación con iOS, es más probable que las aplicaciones interactúen entre sí en OSX que en iOS).
Y como se dijo antes, la sobrecarga es realmente insignificante en OSX, por lo que la omitieron de esta manera.