¿Cuál es la diferencia entre los atributos atómicos y no atómicos?

https://stackoverflow.com/questions/588866

09-09-2019
|

Pregunta

Qué hacer atomic y nonatomic ¿Qué significan 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?

Solución

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 sólo por la ausencia de nonatomic~~ -- atomic se agregó como palabra clave en versiones recientes de llvm/clang).

Suponiendo que está @synthesizing las implementaciones de métodos, atomic vs.cambios no atómicos el código generado.Si está escribiendo sus propios definidores/obtenedores, atómico/nonatomic/retain/assign/copy son meramente consultivos.(Nota:@synthesize es ahora el comportamiento predeterminado en versiones recientes de LLVM.Tampoco es necesario declarar variables de instancia;También se sintetizarán automáticamente y tendrán una _ antepuesto a su nombre para evitar el acceso directo accidental).

Con "atómico", el setter/getter sintetizado asegurará que un entero El valor siempre lo devuelve el captador o el definidor lo establece, independientemente de la actividad del definidor en cualquier otro subproceso.Es decir, si el subproceso A está en el medio del captador mientras el subproceso B llama al definidor, se devolverá un valor viable real (muy probablemente un objeto liberado automáticamente) a la persona que llama en A.

En nonatomic, no se ofrecen tales garantías.De este modo, nonatomic es considerablemente más rápido que "atómico".

¿Qué significa "atómico"? no lo que debe hacer es ofrecer garantías sobre la seguridad del hilo.Si el subproceso A llama al captador simultáneamente con el subproceso B y C llamando al definidor con valores diferentes, el subproceso A puede obtener cualquiera de los tres valores devueltos: el anterior a la llamada de cualquier definidor o cualquiera de los valores pasados 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.

Sumando a esto:

atomicity de una sola propiedad tampoco puede garantizar la seguridad de los subprocesos cuando están en juego varias 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 fullName entre 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.algún otro tipo de sincronización y/o exclusión que permita excluir el acceso a fullName mientras se actualizan las propiedades dependientes.

Otros consejos

Esto se explica en la documentación de Apple , pero a continuación son algunos ejemplos de lo que está sucediendo realmente. Tenga en cuenta que no hay una palabra clave "atómica", si no se especifica "no atómica", entonces la propiedad es atómico, pero especificando "atómica" explícitamente resultará en 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 complicado:

//@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 tomar una cerradura con el fin de garantizar la seguridad de los subprocesos, y también está golpeando el recuento ref en el objeto (y el recuento autorelease para equilibrarlo) para que el objeto se garantiza la existencia de la persona que llama , de lo contrario no es una condición potencial de carrera si otro hilo está fijando el valor, haciendo que el recuento ref caiga a 0.

En realidad, hay un gran número de diferentes variantes de cómo funcionan las cosas en función de si las propiedades son valores escalares u objetos, y cómo retener, copiar, de sólo lectura, no atómica, etc. interactuar. En general, los sintetizadores de propiedad sólo saben cómo hacer "lo correcto" para todas las combinaciones.

Atómica

es el comportamiento por defecto
asegurará el presente proceso se completa por la CPU, antes de que otro proceso tiene acceso a la variable
No es rápido, ya que garantiza el proceso se ha completado en su totalidad

No-Atómica

no es el comportamiento por defecto
más rápido (para el código sintetizado, es decir, para las variables creadas utilizando @property y @synthesize)
no thread-safe
puede resultar en un comportamiento inesperado, cuando dos acceso proceso diferente la misma variable al mismo tiempo

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 [self setName:@"A"] a partir de hilos A, llame [self setName:@"B"] a partir de hilos B, y llamar [self name] a partir de hilos C, entonces todas las operaciones sobre diferentes temas se llevarán a cabo en serie que significa que si un hilo está ejecutando un setter o getter, a continuación, otros hilos esperarán.

Esto hace que la propiedad "nombre" leer / escribir seguro, pero si otro hilo, D, llama al mismo tiempo [name release] entonces 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 promotor debe asegurar de hilo de seguridad para tales 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 puede ejecutar en paralelo.

La sintaxis y la semántica ya están bien definidos por otros excelentes respuestas a esta pregunta. Debido a que ejecución y 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 el uso de 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 nonatomic todo 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 encontrado algunos resultados curiosos.

Ejecución

Ok. 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 implementación no realmente @synchronized(self) uso; 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 / liberación de los objetos dentro del captador.

Rendimiento

Aquí está la parte interesante: Rendimiento propiedad atómica utilizando accesos en indiscutible (por ejemplo, un único subproceso) de los casos puede 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 impugnada caso utilizando 7 hilos fue de 44 veces más lento para el struct de tres bytes (2,2 GHz Core i7 de cuatro núcleos , 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 NSString getter en indiscutible casos (valores en segundos):

MRC | no atómica | captadores implementadas de forma manual: 2
MRC | no atómica | getter sintetizado: 7
MRC | atómica | getter sintetizado: 47
ARC | no atómica | captador sintetizado: 38 (nota: la adición de recuento ref ciclismo de ARC aquí)
ARC | atómica | getter sintetizado: 47

Como se habrá adivinado, la actividad cuenta de referencia / ciclismo es un importante contribuyente a las atómicas y bajo ARC. También se vería greater diferencias en casos controvertidos.

A pesar de que prestar mucha atención al rendimiento, sigo diciendo Semántica primero! . Mientras tanto, el rendimiento es una prioridad baja para muchos proyectos. Sin embargo, conocer los 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. Con suerte, esto le ahorrará unas pocas horas de comparaciones, y ayudarle a tomar una mejor decisión informada en el diseño de programas.

Atómica = hilo de seguridad

no atómica = No seguridad hilo

Seguridad de los hilos:

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 por parte de la llamada código.

En nuestro contexto:

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.

Donde utilizar `atomic`:

si se puede acceder va a la variable de instancia en un entorno multiproceso.

Implicación de `atomic`:

No es tan rápido como nonatomic porque nonatomic no requiere ningún trabajo de vigilancia en el que a partir de tiempo de ejecución.

Donde utilizar `nonatomic`:

Si la variable de instancia no va a ser cambiado por múltiples hilos que puedan utilizarlo. 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 el 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 CPU.

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 se intercambió en la CPU.

Debido a que las variables atomic no pueden ser interrumpidas, el valor contenido por ellos en cualquier punto es (rosca-lock) garantiza que sea uncorrupted , aunque, asegurando este bloqueo de rosca hace que el acceso a ellos más lento. las variables non-atomic, 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-atomic cuando 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 // por defecto
nonatomic
strong = retain // por defecto
weak = unsafe_unretained
retain
assign // por defecto
unsafe_unretained
copy
readonly
readwrite // por defecto

En el artículo propiedad variable atributos o modificadores en iOS se encuentran todas las cualidades antes mencionadas, y que sin duda le ayudará.

atomic
- atomic significa un solo acceso hilo la variable (tipo estático).
- atomic es seguro para subprocesos.
- pero es lento en el rendimiento
- atomic es el comportamiento por defecto
- accessors atómica en un entorno no basura recogida (es decir, cuando el uso de retener / release / autorelease) utilizará una cerradura para asegurar que otro hilo no interfiere con el ajuste correcto / obtener del valor.
- No es en realidad una palabra clave.
Ejemplo:
```
    @property (retain) NSString *name;

    @synthesize name;
```
nonatomic
- nonatomic significa acceso hilo múltiple la variable (tipo dinámico).
- nonatomic es thread-inseguro.
- Pero es rápido en el rendimiento
- nonatomic no es el comportamiento por defecto. Tenemos que añadir la palabra clave nonatomic en el atributo de la propiedad.
- Puede resultar en un comportamiento inesperado, cuando dos procesos diferentes (hilos) acceden a la misma variable al mismo tiempo.
Ejemplo:
```
    @property (nonatomic, retain) NSString *name;

    @synthesize name;
```

Atómica:

garantías atómicos que el acceso a la propiedad se llevarán a cabo de forma atómica. P.ej. que siempre vuelven a objetos totalmente inicializado, cualquier get / set de una propiedad en un subproceso debe completar antes de que otro se puede acceder a él.

Si usted se imagina la siguiente función que ocurre en dos hilos a la vez que se puede ver por qué los resultados no serían bastante.

-(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: Envío de objetos totalmente inicializado cada vez que lo hace mejor opción en caso de multi-threading.

Contras: impacto en el rendimiento, hace que la ejecución de un poco más lento

no atómica:

A diferencia Atómica, que no garantiza objeto totalmente inicializado volver cada vez.

Pros: ejecución extremadamente rápida.

Contras: Las posibilidades de valor de la basura en caso de multi-threading.

respuesta más fácil primero: No hay ninguna diferencia entre los segundos dos ejemplos. Por defecto, acceso de propiedad son atómicos.

accessors atómica en un entorno de recogida de basura no (es decir, cuando el uso de retener / release / autorelease) utilizará una cerradura para asegurar que otro hilo no interfiere con el ajuste correcto / obtener del valor.

Vea la " rendimiento y roscado " de la documentación de Apple Objective-C 2.0 para algunos más información y para otras consideraciones al crear aplicaciones multi-hilo.

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 acceden a la (tipo dinámico) variable. No atómica es hilo-seguro, pero es rápido.

Atómica es hilo seguro , es lentos y TI así-asegura (no garantizado) que sólo se proporciona 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 usted contrata a un experto conductor de 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 rosca propiedad segura. por ejemplo, si u han escrito:

self.myProperty = value;

es seguro para subprocesos.

[myArray addObject:@"Abc"]

no está de 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 estoy recibiendo problemas si uso @property (atómica, retener) NSString * miCadena .

La por defecto es atomic, esto significa que le cuesta 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 otro lado hace nonatomic añadir 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ómica es el valor predeterminado: si no escribe nada, es su propiedad   atómico. Una propiedad atómica se garantiza que si se intenta leer desde   él, que se pondrá en un valor válido. No se hace ninguna garantía   acerca de lo que podría ser ese valor, pero que se pondrá en contacto buenos datos, no   Memoria de basura justo. Lo que esto le permite hacer es si usted tiene múltiples   hilos o múltiples procesos que señalan en una sola variable, uno   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:   ya sea antes del cambio o después del cambio. Lo atómica no lo hace   darle es cualquier tipo de garantía sobre cuál de esos valores se   podría obtener. Atómica está realmente confundido comúnmente con ser seguro para subprocesos,   y eso no es correcto. Es necesario para garantizar su seguridad hilo   otras maneras. Sin embargo, atómica garantizará que si se intenta leer,   vuelvas algún tipo de valor.

no atómica

Por otro lado, no atómica, como es fácil adivinar, sólo significa que,   “No haga eso atómica.” Lo que se pierde es que la garantía de que se   Siempre volver algo. Si intenta leer en el medio de una   escribe, usted 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   a garantizar que va a volver un valor, que son un poco más lento. Si   es una propiedad que está accediendo a una gran cantidad, es posible que desee dejar caer   a no atómica para asegurarse de que usted no está incurriendo en esa velocidad   penalti.

Ver más aquí: https://realm.io/news/tmi-objective-c- propiedad-atributos /

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-hilo.

-Atomic significa un solo acceso hilo la variable (tipo estático).
-Atomic es seguro para subprocesos.
-pero es lento en el rendimiento

¿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 de forma asíncrona).

Si llama "nombre" a partir de hilos

Al mismo tiempo, si se llama

[self setName:@"Datta"]

a partir de hilos B ,

Ahora Si * propiedad name es no atómica después

Se devolverá el valor "Datta" para A
Se devolverá el valor "Datta" para B

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 Si * propiedad de nombre es atómica

Se asegurará de valor "sourov" para A
A continuación, se devolverá el valor "Datta" para B

Es por eso que se llama atómica hilo de seguridad y Es por eso que se llama lectura-escritura segura

Tal operación situación va a realizar en serie. y lento en el rendimiento

- no atómica significa acceso múltiple hilo la variable (tipo dinámico)

- 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 En Swift Confirmando que las propiedades son Swift no atómica en el sentido ObjC. Una de las razones es por lo que piensa acerca de si por la propiedad de atomicidad 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 / propiedad-variable-atributos-or.html

Antes de comenzar: Debe saber que cada objeto en la memoria necesita ser desasignado de la memoria para un nuevo escritor que suceda. No se puede simplemente escribir en la parte superior de algo como lo hace en el papel. debe primero de borrado (dealloc) y luego se puede escribir en él. Si en el momento en que se realiza el borrado (o medio hecho) y nada tiene todavía ha escrito (o la mitad escribió) y se intenta leer podría ser muy problemático! ayuda atómica y no atómica a tratar este problema de diferentes maneras.

En primer lugar, consulte esta pregunta y luego leer respuesta de Bbum. Además, a continuación, leer mi resumen.

atomic garantizará siempre

Si dos personas diferentes quieren leer y escribir al mismo tiempo, su papel no sólo va a quemar! -.> Su aplicación nunca se colgará, incluso en una condición de carrera
Si una persona está tratando de escribir y sólo ha escrito 4 de los 8 cartas que escribir, entonces no se puede leer en el medio, la lectura sólo puede hacerse cuando todos los 8 letras se escribe -> No leer (obtener) que va a pasar en 'un hilo que sigue escribiendo', es decir, si hay 8 bytes en bytes a ser escrito, y sólo 4 bytes están escritas - hasta ese momento, no se le permite leer de él. Pero ya que me dijo que no se bloqueará entonces sería leer el valor de un autoreleased objeto.
Si antes de escrito Tienes borra lo escrito anteriormente sobre el papel y luego alguien quiere leer que puede todavía leer. ¿Cómo? Usted va a leer a partir de algo similar a Mac OS compartimiento de basura (no como compartimiento de basura está siendo del 100% borra ... está en un limbo) ---> Si ThreadA es leer mientras ThreadB ya ha desasignado para escribir, se obtendría un valor, ya sea del valor final totalmente escrito por ThreadB o conseguir algo de la piscina autorelease.

Conservar los que 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 objeto de un mensaje de retener, conservar su recuento se incrementa en 1. Cuando se envía un objeto un mensaje de liberación, su retener cómputo es reducido en 1. Cuando se envía un objeto de un mensaje autorelease , su recuento de retener 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.

Atómica no seguridad de los subprocesos de garantía, aunque es útil para lograr la seguridad de los subprocesos. Hilo de seguridad es relativa a la forma de escribir el código / qué cola de hilo que está leyendo / escribiendo desde. Lo único que garantiza multihilo no crashable.

¿Qué ?! Se multihilo y seguridad 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, que 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, tenemos que escribir nuestro código de una manera segura para los subprocesos uso de bloqueos, mutex o sincronización.

nonatomic

Dado que no hay tal cosa como Mac OS papelera, a continuación, a nadie le importa si está o no siempre se obtiene un valor (<- Esto podría conducir a un accidente), ni nadie le importa si alguien intenta leer la mitad de su escribir (aunque a mitad de camino a escribir en memorY es muy diferente a escribir a mitad de camino en el papel, en la memoria se le podría dar un valor estúpida locura de delante, mientras que en el papel que sólo se ve la mitad de lo que se ha escrito) -> no garantiza que no accidente, ya que doesn' t mecanismo uso autorelease.
No garantiza valores de plena escrito para ser leído!
¿Es más rápido que atómica

En general son diferentes en 2 aspectos:

se caiga o no a causa de tener o no tener una piscina autorelease.
Permitir a ser leído en medio de una 'escritura aún no terminado o valor vacío' o no permitir y sólo permite leer cuando el valor es completamente escrito.

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 simplemente establecer o devolver un valor sintetizado 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ápido.

La atomicidad atómica (por defecto)

Atómica es el valor predeterminado: si no escribe nada, es su propiedad atómico. Una propiedad atómica se garantiza que si se intenta leer desde él, que se pondrá en un valor válido. No se hace ninguna garantía acerca de lo que podría ser ese valor, pero que se pondrá en contacto buenos datos, no Memoria de basura justo. Lo que esto le permite hacer es si usted tiene múltiples hilos o múltiples procesos que señalan en una sola variable, uno 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: ya sea antes del cambio o después del cambio. Lo atómica no lo hace darle es cualquier tipo de garantía sobre cuál de esos valores se podría obtener. Atómica está realmente confundido comúnmente con ser seguro para subprocesos, y eso no es correcto. Es necesario para garantizar su seguridad hilo otras maneras. Sin embargo, atómica garantizará que si se intenta leer, vuelvas algún tipo de valor.

no atómica

Por otro lado, no atómica, como es fácil adivinar, sólo significa que, “No haga eso atómica.” Lo que se pierde es que la garantía de que se Siempre volver algo. Si intenta leer en el medio de una escribe, usted 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 a garantizar que va a volver un valor, que son un poco más lento. Si es una propiedad que está accediendo a una gran cantidad, es posible que desee dejar caer a no atómica para asegurarse de que usted no está incurriendo en esa velocidad multa. El acceso

https://academy.realm.io/posts / TMI-Objective-C-propiedad-atributos /

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 importada se accede desde 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/ atómicas-vs-no-atómicas-properties-crash-supuesto-d11c23f4366c

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 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);
    }

Propiedades atómicas : -. Cuando una variable asignada a la propiedad atómica que significa que tiene un solo acceso hilo y será seguro para subprocesos y será bueno en perspectiva de rendimiento, tendrá un comportamiento por defecto

Propiedades Atómica no : - 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.

Para simplificar toda la confusión, vamos a entender bloqueo de exclusión mutua.

cerradura objeto mutex, como por el nombre, bloquea la mutabilidad del objeto. Así que si el objeto se accede por una clase, ninguna otra clase puede acceder al mismo objeto.

En iOS, @sychronise también proporciona el bloqueo mutex .Now sirve en modo FIFO y asegura el flujo no se ve afectada por dos clases que comparten la misma instancia. Sin embargo, si la tarea es el hilo principal, evitar el acceso a los objetos utilizando las propiedades atómicas, ya que puede contener la interfaz de usuario y degradar el rendimiento.

atómico:. Asegúrese de hilo 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

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow