¿Qué significan atomicy nonatomicsignifican en las declaraciones de propiedad?
@property(nonatomic, retain) UITextField *userName;
@property(atomic, retain) UITextField *userName;
@property(retain) UITextField *userName;
¿Cuál es la diferencia operativa entre estos tres?
Los dos últimos son idénticos; "atómico" es el comportamiento predeterminado ( tenga en cuenta que en realidad no es una palabra clave; se especifica solo por la ausencia de - nonatomicatomicse agregó como palabra clave en las versiones recientes de llvm / clang).
Suponiendo que estás sintetizando las implementaciones del método, los cambios atómicos y no atómicos cambian el código. Si está escribiendo su propio setter / getters, atomic / nonatomic / retain / assign / copy son meramente asesores. (Nota: @synthesize es ahora el comportamiento predeterminado en las versiones recientes de LLVM. Tampoco es necesario declarar variables de instancia; también se sintetizarán automáticamente y se agregarán _a su nombre para evitar el acceso directo accidental).
Con "atómico", el setter / getter sintetizado asegurará que siempre se devuelva un valor completo desde el getter o el setter, independientemente de la actividad del setter en cualquier otro thread. Es decir, si el hilo A está en el medio del captador mientras el hilo B llama al colocador, un valor viable real, es decir, un objeto liberado automáticamente, se devolverá a la persona que llama en A.
En nonatomic, no se hacen tales garantías. Por lo tanto, nonatomices considerablemente más rápido que "atómico".
Lo que "atómico" no hace es dar garantías sobre la seguridad del hilo. Si el subproceso A llama al captador de forma simultánea con el subproceso B y C llamando al instalador con valores diferentes, el subproceso A puede obtener cualquiera de los tres valores devueltos, el anterior a que se invoque a cualquier ajustador o se pase cualquiera de los valores a los definidores en B y C. Del mismo modo, el objeto puede terminar con el valor de B o C, no hay forma de saberlo.
Garantizar la integridad de los datos, uno de los principales desafíos de la programación multiproceso, se logra por otros medios.
Agregando a esto:
atomicity de una sola propiedad tampoco puede garantizar la seguridad del hilo cuando están en juego múltiples propiedades dependientes.
Considerar:
@property(atomic, copy) NSString *firstName;
@property(atomic, copy) NSString *lastName;
@property(readonly, atomic, copy) NSString *fullName;
En este caso, el hilo A podría estar cambiando el nombre del objeto llamando setFirstName:y luego llamando setLastName:. Mientras tanto, el hilo B puede llamar fullNameentre las dos llamadas del hilo A y recibirá el nuevo nombre junto con el apellido anterior.
Para abordar esto, necesita un modelo transaccional . Es decir, otro tipo de sincronización y / o exclusión que permite excluir el acceso fullNamemientras se actualizan las propiedades dependientes.
Esto se explica en la documentación de Apple , pero a continuación hay algunos ejemplos de lo que realmente está sucediendo. Tenga en cuenta que no hay palabra clave "atómica", si no especifica "no atómica", la propiedad es atómica, pero especificar "atómico" explícitamente dará como resultado un error.
//@property(nonatomic, retain) UITextField *userName;
//Generates roughly
- (UITextField *) userName {
return userName;
}
- (void) setUserName:(UITextField *)userName_ {
[userName_ retain];
[userName release];
userName = userName_;
}
Ahora, la variante atómica es un poco más complicada:
//@property(retain) UITextField *userName;
//Generates roughly
- (UITextField *) userName {
UITextField *retval = nil;
@synchronized(self) {
retval = [[userName retain] autorelease];
}
return retval;
}
- (void) setUserName:(UITextField *)userName_ {
@synchronized(self) {
[userName_ retain];
[userName release];
userName = userName_;
}
}
Básicamente, la versión atómica tiene que cerrarse para garantizar la seguridad del hilo, y también está superando el recuento de ref en el objeto (y el recuento de liberación automática para equilibrarlo) de modo que el objeto está garantizado para la persona que llama, de lo contrario habrá es una condición de carrera potencial si otro hilo está configurando el valor, lo que hace que el recuento de ref se reduzca a 0.
En realidad, hay una gran cantidad de variantes diferentes de cómo funcionan estas cosas, dependiendo de si las propiedades son valores u objetos escalares, y cómo interactúan retención, copia, solo lectura, no atómica, etc. En general, los sintetizadores de propiedades solo saben cómo hacer lo "correcto" para todas las combinaciones.
La mejor manera de entender la diferencia está utilizando el siguiente ejemplo.
Supongamos que hay una propiedad de cadena atómica llamada "nombre", y si se llama a [self setName:@"A"]partir de hilos A, llamada [self setName:@"B"]a partir de hilos B, y llame [self name]a partir de hilos C, a continuación, se llevarán a cabo todas las operaciones en diferentes hilos en serie que significa que si un hilo está ejecutando un colocador o captador, a continuación, otros hilos van a esperar.
Esto hace que la propiedad "nombre" leer / escribir seguro, pero si otro hilo, D, llama [name release]al mismo tiempo a continuación, esta operación podría producir un accidente, porque no hay ninguna llamada setter / getter involucrado aquí. Lo que significa que un objeto es de lectura / escritura de seguridad (atómico), pero no el hilo de seguridad como otro hilos pueden enviar simultáneamente cualquier tipo de mensajes al objeto. El desarrollador debe asegurarse de hilo de seguridad para este tipo de objetos.
Si la propiedad "nombre" era no atómica, a continuación, todos los hilos en ejemplo anterior - A, B, C y D se ejecutan producir simultáneamente cualquier resultado impredecible. En caso de atómico, ya sea uno de A, B o C se ejecutará primero, pero D todavía se pueden ejecutar en paralelo.
La sintaxis y la semántica ya están bien definidos por otros excelentes respuestas a esta pregunta. Debido a la ejecución y el rendimiento no se detallan así, voy a añadir mi respuesta.
¿Cuál es la diferencia funcional entre estos 3?
Siempre había considerado atómica como un defecto bastante curiosa. A nivel de abstracción, trabajamos en, utilizando las propiedades atómicas para una clase como un vehículo para lograr el 100% de hilo de seguridad es un caso límite. Para programas multihilo verdaderamente correctas, la intervención del programador es casi seguro que un requisito. Mientras tanto, las características de rendimiento y ejecución aún no se han detallado en profundidad. Después de haber escrito algunos programas multihilo en gran medida en los últimos años, había estado declarando mis propiedades como nonatomictodo el tiempo porque atómica no era adecuada para cualquier propósito. Durante la discusión de los detalles de las propiedades atómicas y no atómicas esta pregunta , he hecho un poco de perfiles se encontró con algunos resultados curiosos.
Ejecución
De acuerdo. La primera cosa que me gustaría aclarar es que la aplicación de bloqueo es definido por la implementación y abstraído. Louis utiliza @synchronized(self)en su ejemplo - he visto esto como una fuente común de confusión. La aplicación no realmente usar @synchronized(self); se utiliza el nivel de objeto bloqueos de giro . Ilustración de Louis es bueno para una ilustración de alto nivel utilizando construcciones que todos conocemos, pero es importante saber que no utiliza @synchronized(self).
Otra diferencia es que las propiedades atómicas conservarán / ciclo de liberación de los objetos dentro del captador.
Actuación
Aquí está la parte interesante: Rendimiento propiedad atómica utilizando accesos en indiscutible (por ejemplo, un único subproceso) de los casos pueden ser realmente muy rápido en algunos casos. En menos que ideal casos, el uso de accesos atómicas puede costar más de 20 veces la sobrecarga de nonatomic. Mientras que el Contested caso utilizando 7 hilos fue de 44 veces más lenta para la struct de tres bytes (2,2 GHz Core i7 Quad Core, x86_64). La estructura de tres bytes es un ejemplo de una propiedad muy lento.
Nota interesante: descriptores de acceso definidos por el usuario de la estructura de tres bytes eran 52 veces más rápido que los descriptores de acceso atómicas sintetizados; o 84% de la velocidad de descriptores de acceso no atómicas sintetizados.
Los objetos en casos controvertidos también pueden exceder de 50 veces.
Debido al número de optimizaciones y variaciones en las implementaciones, es muy difícil medir el impacto del mundo real en estos contextos. A menudo se puede escuchar algo como "Confía en él, a menos que de perfil y encontrar que es un problema". Debido al nivel de abstracción, de hecho es bastante difícil medir el impacto real. Espigando los costes reales de los perfiles puede ser mucho tiempo, y debido a las abstracciones, bastante inexacta. Además, ARC vs MRC puede hacer una gran diferencia.
Así que vamos a dar un paso atrás, no se centra en la aplicación de la propiedad accesos, incluiremos los sospechosos habituales, como objc_msgSend, y examinar algunos resultados de alto nivel del mundo real para muchas llamadas a un NSStringcaptador en impugnados casos (valores en segundos):
Como se habrá adivinado, el recuento de referencia de la actividad / ciclismo es un importante contribuyente a las atómicas y bajo ARC. También podría ver mayores diferencias en los casos controvertidos.
A pesar de que prestar mucha atención al rendimiento, sigo diciendo Semántica En primer lugar! . Mientras tanto, el rendimiento es una prioridad baja para muchos proyectos. Sin embargo, conociendo detalles de ejecución y los costos de las tecnologías que utiliza ciertamente no hace daño. Se debe utilizar la tecnología adecuada para sus necesidades, propósitos y capacidades. Esperemos que esto le ahorrará unas pocas horas de comparaciones, y ayudarle a tomar una decisión mejor informada en el diseño de programas.
Atómica = seguridad hilo
No atómica = No seguridad hilo
Las variables de instancia son thread-safe si se comportan correctamente cuando se accede desde múltiples hilos, independientemente de la programación o entrelazado de la ejecución de dichos hilos por el entorno de ejecución, y con ninguna sincronización adicional o de coordinación en la parte del código de llamada.
Si un hilo cambia el valor de la instancia el valor modificado está disponible para todos los hilos, y sólo un hilo puede cambiar el valor a la vez.
atomic:si se puede acceder va a la variable de instancia en un entorno multiproceso.
atomic:No tan rápido como nonatomicporque nonatomicno requiere ningún trabajo de vigilancia en el que a partir de tiempo de ejecución.
nonatomic:Si la variable de instancia no va a ser cambiado por múltiples hilos que se puede utilizar. Mejora el rendimiento.
He encontrado una explicación bastante bien poner de propiedades atómicas y no atómicas aquí . Aquí hay algo de texto relevante de la misma:
'atómica' significa que no se puede dividir. En términos / OS de programación una llamada de función atómica es uno que no puede ser interrumpido - la función entera debe ser ejecutado, y no cambió de la CPU por el contexto habitual del sistema operativo de conmutación hasta que sea completa. Sólo en caso de que no lo sabía: desde la CPU sólo puede hacer una cosa a la vez, el sistema operativo gira el acceso a la CPU a todos los procesos que se ejecutan en poco tiempo-rebanadas, para dar la ilusión de multitarea. El planificador de la CPU puede (y lo hace) interrumpir un proceso en cualquier momento de su ejecución - incluso en mitad de una llamada de función. Así que para acciones tales como la actualización de variables de control compartidos donde dos procesos podrían tratar de actualizar la variable al mismo tiempo, deben ser ejecutados 'atómicamente', es decir, cada acción de actualización tiene que terminar en su totalidad antes de que cualquier otro proceso se puede cambiar en el UPC.
Así que estaría adivinando que atómica en este caso significa los métodos lector atributo no pueden ser interrumpidas - en efecto, lo que significa que la variable (s) siendo leído por el método no puede cambiar su valor a medio camino debido a algún otro flujo / llamada / función obtiene intercambiado en la CPU.
Debido a que las atomicvariables no pueden ser interrumpidas, el valor contenido por ellos en cualquier punto es (rosca de frenos) garantiza que sea sin corrupción , aunque, asegurando de este bloqueo de rosca hace que el acceso a ellos más lento. non-atomiclas variables, por el contrario, no hacen ninguna garantía de tal, pero sí ofrecen el lujo de un acceso más rápido. Para resumir, ir con non-atomiccuando se sabe sus variables no se puede acceder por múltiples hilos simultáneamente y acelerar las cosas.
Después de leer tantos artículos, Stack Overflow mensajes y hacer aplicaciones de demostración para comprobar los atributos de propiedad variables, decidí poner toda la información atributos juntos:
atomic // Defectononatomicstrong = retain // Defectoweak = unsafe_unretainedretainassign // Defectounsafe_unretainedcopyreadonlyreadwrite // DefectoEn el artículo de atributos de propiedad variable o modificadores en iOS se pueden encontrar todos los atributos antes mencionados, y que sin duda le ayudará.
atomic
atomic medios solamente un acceso hilo la variable (tipo estático).atomic se subprocesos.atomic es el comportamiento por defectoEjemplo:
@property (retain) NSString *name;
@synthesize name;
nonatomic
nonatomic medios de acceso múltiple hilo la variable (tipo dinámico).nonatomic es thread-inseguro.nonatomicNO se comportamiento predeterminado. Tenemos que añadir la nonatomicpalabra clave en el atributo de propiedad.Ejemplo:
@property (nonatomic, retain) NSString *name;
@synthesize name;
La respuesta más fácil primero: no hay diferencia entre los dos segundos ejemplos. Por defecto, los accesores de propiedad son atómicos.
Los accesadores atómicos en un entorno no recogido de basura (es decir, cuando se usa retener / liberar / autorrelease) utilizarán un bloqueo para garantizar que otro subproceso no interfiera con la configuración / obtención correcta del valor.
Consulte la sección " Rendimiento y subprocesamiento " de la documentación de Objective-C 2.0 de Apple para obtener más información y otras consideraciones al crear aplicaciones de subprocesos múltiples.
Garantías atómicas de que el acceso a la propiedad se realizará de forma atómica. Por ejemplo, siempre devuelve un objeto completamente inicializado, cualquier obtención / conjunto de una propiedad en un hilo debe completarse antes de que otro pueda acceder a él.
Si imagina que la siguiente función se produce en dos hilos a la vez, puede ver por qué los resultados no serían bonitos.
-(void) setName:(NSString*)string
{
if (name)
{
[name release];
// what happens if the second thread jumps in now !?
// name may be deleted, but our 'name' variable is still set!
name = nil;
}
...
}
Pros: El retorno de objetos completamente inicializados cada vez lo convierte en la mejor opción en caso de multi-threading.
Contras: golpe de rendimiento, hace que la ejecución sea un poco más lenta
A diferencia de Atomic, no asegura el retorno del objeto completamente inicializado cada vez.
Pros: ejecución extremadamente rápida.
Contras: Posibilidades de valor de basura en caso de multi-threading.
Atómica significa sólo un hilo accede a la variable (tipo estático). Atómico es seguro para subprocesos, pero es lento.
No atómica significa múltiples hilos acceder a la variable (tipo dinámico). No atómica es hilo-seguro, pero es rápida.
Atómico es seguro para subprocesos , es lenta y TI así asegura-(no garantizado) que sólo se presta el valor bloqueado no importa cuántos hilos están intentando acceder a más de la misma zona. Al utilizar atómica, una pieza de código escrito dentro de esta función se convierte en parte de la sección crítica, a la que sólo un hilo puede ejecutar a la vez.
Es sólo asegura la seguridad hilo; no garantiza eso. Lo que quiero decir es que contrate un conductor experto para su coche, todavía no garantiza coche no va a cumplir un accidente. Sin embargo, la probabilidad sigue siendo el más mínimo.
Atómica - no se puede dividir, por lo que se espera el resultado. Con no atómica - cuando otro acceso rosca la zona de memoria que puede modificar, así que el resultado es inesperado.
Código de conversación:
Atómica hacer get y set de la caja fuerte del hilo propiedad. por ejemplo, si u han escrito:
self.myProperty = value;
se subprocesos.
[myArray addObject:@"Abc"]
NO se subprocesos.
No hay tal palabra clave "atómica"
@property(atomic, retain) UITextField *userName;
Podemos utilizar lo anterior como
@property(retain) UITextField *userName;
Véase la pregunta de desbordamiento de pila que estoy recibiendo problemas si uso @property (atómica, retener) NSString * miCadena .
El valor predeterminado es atomic, esto significa que hace le costará un rendimiento cada vez que se utiliza la propiedad, pero es seguro para subprocesos. Lo Objective-C no, se establece un bloqueo, por lo que sólo el hilo real puede acceder a la variable, siempre y cuando se ejecuta el setter / getter.
Ejemplo con MRC de una propiedad con una _internal Ivar:
[_internal lock]; //lock
id result = [[value retain] autorelease];
[_internal unlock];
return result;
Así que estos dos últimos son los mismos:
@property(atomic, retain) UITextField *userName;
@property(retain) UITextField *userName; // defaults to atomic
Por otra parte lo hace nonatomicno añaden nada a su código. Por lo que sólo se hilo de seguridad si el código mecanismo de seguridad a sí mismo.
@property(nonatomic, retain) UITextField *userName;
Las palabras clave no tiene que ser escrito como atributo primera propiedad en absoluto.
No se olvide, esto no significa que la propiedad en su conjunto es seguro para subprocesos. Sólo la llamada al método del colocador / captador es. Pero si se utiliza un regulador y después de que un captador al mismo tiempo, con 2 hilos diferentes, podría romperse también!
atómica (por defecto)
Atómico es el valor por defecto: si no escribe nada, es su propiedad atómica. Una propiedad atómica se garantiza que si se intenta leer de él, que se pondrá en un valor válido. No se hace ninguna garantía sobre cuál podría ser ese valor, pero que se pondrá en contacto buenos datos, no sólo la memoria de la chatarra. Lo que esto le permite hacer es si tiene varios hilos o procesos múltiples que apuntan a una sola variable, un hilo puede leer y otro hilo puede escribir. Si golpean al mismo tiempo, el hilo lector está garantizado para conseguir uno de los dos valores: o bien antes del cambio o después del cambio. Lo atómica no le da algún tipo de garantía sobre cuál de esos valores que podría obtener. Atómico es muy comúnmente confundido con ser seguro para subprocesos, y eso no es correcto. Es necesario para garantizar su seguridad hilo de otras maneras. Sin embargo, atómica garantizará que si se intenta leer, a volver algún tipo de valor.
no atómica
Por otro lado, no atómica, como es fácil adivinar, simplemente significa, “no hacer esas cosas atómica.” Lo que se pierde es que garantiza que siempre se vuelva algo. Si intenta leer en el medio de una escritura, podría volver datos de la basura. Pero, por otro lado, que vaya un poco más rápido. Dado que las propiedades atómicas tienen que hacer un poco de magia para garantizar que va a volver un valor, que son un poco más lento. Si se trata de una propiedad que está accediendo a una gran cantidad, es posible que desee bajar a no atómica para asegurarse de que usted no está incurriendo en que la pérdida de velocidad.
Ver más aquí: https://realm.io/news/tmi-objective-c-property-attributes/
¿Cómo declarar:
Como atómica es por defecto es así,
@property (retain) NSString *name;
Y en el archivo de implementación
self.name = @"sourov";
Supongamos que una tarea relacionada con tres propiedades son
@property (retain) NSString *name;
@property (retain) NSString *A;
@property (retain) NSString *B;
self.name = @"sourov";
Todas las propiedades funcionan en paralelo (como asíncrona).
Si llama "nombre" a partir de hilos Una ,
Y
Al mismo tiempo, si se llama
[self setName:@"Datta"]
a partir de hilos B ,
Ahora bien, si * nombre de la propiedad es no atómica entonces
Es por eso que no se llama atómica hilo insegura Pero pero es rápido en el rendimiento debido a la ejecución en paralelo
Ahora bien, si la propiedad * nombre es atómica
Es por eso que se llama atómica hilo de seguridad y es por eso que se llama lectura y escritura segura
Tal operación situación llevará a cabo en serie. Y lento en el rendimiento
- no atómica significa acceso rosca múltiple, el (tipo dinámico) variable.
- no atómica es hilo inseguro.
- pero es rápido en el rendimiento
-Nonatomic NO es un comportamiento predeterminado, tenemos que añadir la palabra clave no atómica en el atributo de propiedad.
Para Swift En Confirmando que son propiedades Swift no atómica en el sentido ObjC. Una de las razones es por lo que piensa acerca de si la atomicidad por la propiedad es suficiente para sus necesidades.
Referencia: https://forums.developer.apple.com/thread/25642
El Para más información, visite el sitio web http://rdcworld-iphone.blogspot.in/2012/12/variable-property-attributes-or.html
Si está utilizando su propiedad en el código multihilo, entonces sería capaz de ver la diferencia entre atributos no atómicos y nucleares. No atómica es más rápido que atómica y nuclear es segura para los subprocesos, no no atómica.
Vijayendra Tripathi ya ha dado un ejemplo de un entorno multi-roscado.
Antes de comenzar: Debe saber que cada objeto en la memoria necesita ser desasignado de la memoria para una nueva escritura suceda. No se puede simplemente escribir en la parte superior de algo como lo hace en el papel. Usted debe primero borrar (dealloc) y luego se puede escribir en él. Si en el momento que el borrado se realiza (o medio hecho) y nada todavía no se ha escrito (o la mitad escribió) y se intenta leer podría ser muy problemático! Ayuda atómica y no atómica que tratar este problema de diferentes maneras.
Primero lea esta pregunta y luego leer la respuesta de Bbum . Además luego leer mi resumen.
atomic se garantizan siempre
Retener cuenta son la forma en que se gestiona la memoria en Objective-C. Cuando se crea un objeto, que tiene un recuento de retener 1. Cuando se envía un mensaje un objeto conservar, mantener su recuento se incrementa en 1. Cuando se envía un objeto un mensaje de liberación, su retener recuento se decrementa en 1. Cuando enviar un objeto de un mensaje de autorelease , su retener recuento se disminuye en 1 en algún momento en el futuro. Si un object's conservan recuento se reduce a 0, se cancela la asignación.
¡¿Esperar lo?! Se multihilo y seguridad de los subprocesos diferente?
Sí. Multihilo significa: múltiples hilos pueden leer una pieza compartida de datos al mismo tiempo y que no van a chocar, sin embargo, no garantiza que usted no está leyendo desde un valor no autoreleased. Con hilo de seguridad, está garantizado que lo que se lee no es auto-editado. La razón de que no hacemos todo lo atómica por defecto es, porque hay un costo de rendimiento y para la mayoría de las cosas realmente no necesita hilo de seguridad. Unas partes de nuestro código lo necesitan y para aquellas pocas partes que tienen que escribir nuestro código de una manera segura usando hilo de cerraduras, mutex o sincronización.
nonatomic
En general son diferentes en 2 aspectos:
Que se caiga o no a causa de tener o no tener piscina autorelease.
Permitiendo a leerse en medio de una 'escritura aún no terminado o valor vacío' o no permitir y sólo permite leer cuando el valor está totalmente escrito.
Antes de discutir sobre los atributos de @property, usted debe saber lo que es el uso de @property. @property ofrece una manera de definir la información que una clase está destinado a encapsular. Si se declara un objeto / variable usando @property, entonces ese objeto / variable será accesible a otras clases importadores de su clase. Si se declara un objeto utilizando @property en el archivo de cabecera, entonces usted tiene que sintetizar usando @synthesize en el archivo de implementación.
Ejemplo:
clase .h
@interface ExampleClass : NSObject
@property (nonatomic, retain) NSString *name;
@end
clase .m
@implementation ExampleClass
@synthesize name;
@end
Ahora el compilador sintetizar métodos de acceso para el nombre.
ExampleClass *newObject=[[ExampleClass alloc]init];
NSString *name1=[newObject name]; // get 'name'
[obj setName:@“Tiger”];
Lista de los atributos de @property: atómica. no atómica. conservar. dupdo. solo lectura. leer escribir. asignar. fuerte.
atómico: Es el comportamiento por defecto. Si un objeto se declara como atómica entonces se convierte en seguro para subprocesos. medios de rosca de seguridad, a la vez sólo un hilo de una instancia determinada de esa clase pueden tener el control sobre ese objeto.
Ejemplo:
@property NSString *name; //by default atomic
@property (atomic)NSString *name; // explicitly declared atomic
no atómica: No es seguro para subprocesos. Puede utilizar el atributo de propiedad no atómica para especificar que los descriptores de acceso sintetizados simplemente establecer o devolver un valor directamente, sin ninguna garantía sobre lo que ocurre si se accede a ese mismo valor de forma simultánea desde diferentes hilos. Por esta razón, es más rápido acceder a una propiedad no atómica que un uno atómica.
@property (nonatomic)NSString *name;
retener: se requiere cuando el atributo es un puntero a un método setter object.The aumentará retener el recuento del objeto, por lo que va a ocupar memoria en la piscina autorelease.
@property (retain)NSString *name;
copia: Si usted usa la copia, no se puede utilizar retener. Usando ejemplo, copia de la clase contendrá su propia copia. Incluso si una cadena mutable se establece y posteriormente cambió, la instancia de captura cualquier valor que tiene en el momento en que se establece. se sintetizarán No hay setter y getter métodos.
@property (copy) NSString *name;
NSMutableString *nameString = [NSMutableString stringWithString:@"Liza"];
xyzObj.name = nameString;
[nameString appendString:@"Pizza"];
de sólo lectura: Si no desea permitir la propiedad de ser cambiado a través de método de selección, se puede declarar la propiedad de sólo lectura.
@property (readonly) NSString *name;
lectura-escritura: es el comportamiento por defecto. No es necesario especificar el atributo de lectura-escritura de forma explícita.
@property (readwrite) NSString *name;
asignar: generará un colocador que asigna el valor de la variable de instancia directamente, en lugar de copiar o retenerlo. Este es el mejor para los tipos primitivos como NSInteger y CGFloat, u objetos que no posee directamente, como delegados.
@property (assign) NSInteger year;
fuerte: es un reemplazo para retener.
@property (nonatomic, strong) AVPlayer *player;
unsafe_unretained: Hay algunas clases en Cocoa y Cocoa Touch que aún no admiten referencias débiles, lo que significa que no se puede declarar una propiedad débil o débil variable local para realizar un seguimiento de ellos. Estas clases incluyen NSTextView, NSFont y NSColorSpace, etc. Si es necesario utilizar una referencia débil para una de estas clases, debe utilizar una referencia inseguro. Una referencia inseguro es similar a una referencia débil, ya que no mantiene su objeto relacionado con vida, pero no se establecerá a cero si se cancela la asignación del objeto de destino.
@property (unsafe_unretained) NSObject *unsafeProperty;
La propiedad atómica asegura retener un valor totalmente inicializado independientemente de cuántos hilos están haciendo getter y setter en él.
La propiedad no atómica especifica que accessors sintetizados simplemente establecer o devolver un valor directamente, sin garantías sobre lo que ocurre si se accede a ese mismo valor simultáneamente a partir de diferentes hilos.
Atómica significa sólo un hilo puede acceder a la variable a la vez (tipo estático). Atómico es seguro para subprocesos, pero es lento.
No atómica significa múltiples hilos pueden acceder a la variable al mismo tiempo (tipo dinámico). No atómica es hilo-seguro, pero es rápida.
Si está utilizando atómica, significa que el hilo podría no ser segura y de sólo lectura. Si está utilizando no atómica, significa que los múltiples subprocesos tienen acceso a la variable y es insegura hilo, pero se ejecuta rápido, realiza una lectura y escritura; este es un tipo dinámico.
La atomicidad atómica (por defecto)
Atómico es el valor por defecto: si no escribe nada, es su propiedad atómica. Una propiedad atómica se garantiza que si se intenta leer de él, que se pondrá en un valor válido. No se hace ninguna garantía sobre cuál podría ser ese valor, pero que se pondrá en contacto buenos datos, no sólo la memoria de la chatarra. Lo que esto le permite hacer es si tiene varios hilos o procesos múltiples que apuntan a una sola variable, un hilo puede leer y otro hilo puede escribir. Si golpean al mismo tiempo, el hilo lector está garantizado para conseguir uno de los dos valores: o bien antes del cambio o después del cambio. Lo atómica no le da algún tipo de garantía sobre cuál de esos valores que podría obtener. Atómico es muy comúnmente confundido con ser seguro para subprocesos, y eso no es correcto. Es necesario para garantizar su seguridad hilo de otras maneras. Sin embargo, atómica garantizará que si se intenta leer, a volver algún tipo de valor.
no atómica
Por otro lado, no atómica, como es fácil adivinar, simplemente significa, “no hacer esas cosas atómica.” Lo que se pierde es que garantiza que siempre se vuelva algo. Si intenta leer en el medio de una escritura, podría volver datos de la basura. Pero, por otro lado, que vaya un poco más rápido. Dado que las propiedades atómicas tienen que hacer un poco de magia para garantizar que va a volver un valor, que son un poco más lento. Si se trata de una propiedad que está accediendo a una gran cantidad, es posible que desee bajar a no atómica para asegurarse de que usted no está incurriendo en que la pérdida de velocidad. Acceso
cortesía https://academy.realm.io/posts/tmi-objective-c-property-attributes/
Atributos de propiedad de atomicidad (atómicas y no atómicas) no se reflejan en la correspondiente declaración de propiedad Swift, pero las garantías atomicidad de la ejecución de Objective-C todavía mantienen cuando la propiedad se accede desde importada Swift.
Por lo tanto - si se define una propiedad atómica en Objective-C seguirá siendo atómica cuando es utilizado por Swift.
cortesía https://medium.com/@YogevSitton/atomic-vs-non-atomic-properties-crash-course-d11c23f4366c
Propiedades atómicas : - Cuando una variable asignada a la propiedad atómica que significa que tiene un solo acceso hilo y el hilo será seguro y estará bien en la perspectiva del rendimiento, tendrá un comportamiento por defecto.
Las propiedades no atómicas : - Cuando una variable asignada a la propiedad atómica que significa que tiene acceso multi hilo y no será hilo de seguridad y será lenta en perspectiva de rendimiento, tendrá un comportamiento por defecto y cuando dos hilos diferentes quieren acceder a la variable al mismo tiempo que dará resultados inesperados.
La verdad es que utilizan bloqueo de bucle para implementar propiedad atómica. El código de la siguiente manera:
static inline void reallySetProperty(id self, SEL _cmd, id newValue,
ptrdiff_t offset, bool atomic, bool copy, bool mutableCopy)
{
id oldValue;
id *slot = (id*) ((char*)self + offset);
if (copy) {
newValue = [newValue copyWithZone:NULL];
} else if (mutableCopy) {
newValue = [newValue mutableCopyWithZone:NULL];
} else {
if (*slot == newValue) return;
newValue = objc_retain(newValue);
}
if (!atomic) {
oldValue = *slot;
*slot = newValue;
} else {
spin_lock_t *slotlock = &PropertyLocks[GOODHASH(slot)];
_spin_lock(slotlock);
oldValue = *slot;
*slot = newValue;
_spin_unlock(slotlock);
}
objc_release(oldValue);
}
Para simplificar toda la confusión vamos a entender bloqueo mutex lock.Mutex según el nombre bloquea la mutabilidad de la object.So si el objeto se accede por una clase de ninguna otra clase puede acceder a la misma @sychronise object.In IOS también proporcionan el mutex lock.Now que sirven en modo FIFO y asegura el flujo no se ve afectada por dos clases que comparten el mismo instance.However si la tarea es evitar el hilo principal objeto el acceso utilizando las propiedades atómicas, ya que puede contener la interfaz de usuario y degradar el rendimiento
Atómica: Asegúrese de hilos de seguridad mediante el bloqueo de la rosca usando NSLOCK.
No atómica: No asegura hilo de seguridad que no existe un mecanismo de bloqueo de rosca.