objective c - las - Uso de propiedades atómicas en el Objetivo C: ¿Algún efecto secundario?
hiroshima y nagasaki causas (2)
No deberías pagar por lo que no usas. A diferencia de las computadoras conectadas donde los ciclos de la CPU le cuestan en términos de tiempo, los ciclos de la CPU en un dispositivo móvil le cuestan tiempo y uso de la batería. Si su aplicación es de un solo hilo, no hay ninguna razón para usar atomic , porque las operaciones de bloqueo y desbloqueo serían una pérdida de tiempo y de batería. La batería es más importante que el tiempo: mientras que la latencia asociada con la adición de operaciones adicionales puede ser invisible para el usuario final, los ciclos gastados reducirán el tiempo que el dispositivo móvil puede funcionar después de una sola carga, una medida que muchos los usuarios lo consideran muy importante.
Entiendo que el significado de atomic se explicó en ¿Cuál es la diferencia entre los atributos atómicos y no atómicos? , pero lo que quiero saber es:
P. ¿Hay efectos secundarios, además de problemas de rendimiento, en el uso de propiedades atómicas en todas partes?
Parece que la respuesta es no, ya que el rendimiento del iPhone es bastante rápido hoy en día. Entonces, ¿por qué tanta gente sigue usando productos non-atomic ?
Incluso atomic no garantiza la seguridad del hilo, pero es mejor que nada, ¿verdad?
Incluso atómico no garantiza la seguridad del hilo, pero es mejor que nada, ¿verdad?
Mal . Después de haber escrito algunos programas simultáneos realmente complejos, recomiendo exactamente lo contrario . Debes reservar atomic para cuando realmente tenga sentido usarlo, y es posible que no lo comprendas completamente hasta que escribas programas concurrentes sin ningún uso de atomic . Si estoy escribiendo un programa multiproceso, no quiero que se enmascaren los errores de programación (p. Ej., Condiciones de carrera). Quiero que los problemas de concurrencia sean fuertes y obvios. De esta forma, son más fáciles de identificar, reproducir y corregir.
La creencia de que la seguridad de algunos hilos es mejor que ninguno es defectuosa. El programa es threadsafe o no lo es. El uso de atomic puede hacer que esos aspectos de tus programas sean más resistentes a los problemas relacionados con la concurrencia, pero eso no te cuesta demasiado. Claro, es probable que haya menos bloqueos, pero el programa sigue siendo indiscutiblemente incorrecto, y todavía explotará de formas misteriosas. Mi consejo: si no vas a tomar el tiempo para aprender y escribir programas simultáneos correctos , solo mantenlos de una sola hebra (si eso suena un poco duro: no está destinado a ser duro, te salvará de muchos dolores de cabeza). ) El subprocesamiento múltiple y la concurrencia son temas enormes y complicados: lleva mucho tiempo aprender a escribir programas verdaderamente correctos y duraderos en muchos dominios.
Por supuesto, atomic se puede usar para lograr la seguridad del hilo en algunos casos, pero hacer que cada acceso atómico no garantice nada para la seguridad del hilo. Además, es altamente inusual (estadísticamente) que atomic propiedades atomic sí solas hagan que una clase sea realmente segura, especialmente a medida que aumenta la complejidad de la clase; es más probable que una clase con un ivar sea verdaderamente segura usando átomos solamente, frente a una clase con 5 ivars. atomic propiedades atomic son una característica que uso muy raramente (de nuevo, algunas bases de código bastante grandes y programas concurrentes). Es prácticamente un caso de esquina si los átomos atómicos son lo que hace que una clase realmente sea segura.
La complejidad del rendimiento y la ejecución son las principales razones para evitarlos. En comparación con los accesos no atómicos, y la frecuencia y simplicidad de acceder a una variable, el uso de atómica se acumula muy rápido. Es decir, los accesos atómicos introducen mucha complejidad de ejecución en relación con la tarea que realizan.
Los bloqueos de giro son una forma en que se implementan las propiedades atómicas. Entonces, ¿desearía que una primitiva de sincronización como un bloqueo por giro o mutex rodee implícitamente cada obtención y conjunto, sabiendo que no garantiza la seguridad del hilo? ¡Ciertamente no! Hacer que cada acceso de propiedad en sus implementaciones atómicas puede consumir una tonelada de tiempo de CPU. Debe usarlo solo cuando tenga una razón explícita para hacerlo (también mencionado por dasblinkenlicht + 1). Detalle de implementación: algunos accesos no requieren cerraduras giratorias para mantener las garantías de atomic ; depende de varias cosas, como la arquitectura y el tamaño de una variable.
Así que para responder a su pregunta "¿algún efecto secundario?" en un formato TL; DR: el rendimiento es la razón principal que usted señaló, mientras que la aplicabilidad de las garantías atómicas y cómo eso es útil para usted es muy estrecha en su nivel de abstracción (a menudo incomprendido) y enmascara errores reales .