8
En Obj-C, ¿qué significa en términos simples; "CoreData no es seguro para subprocesos"¿Qué se entiende por CoreData no es seguro para subprocesos?
O, en general, ¿qué es "no es seguro para subprocesos"?
A
Respuesta
21
@ respuesta de d11wtq es correcta sólo al escribir su propio código o el diseño de sus propias APIs.
Es completamente incorrecto cuando se trabaja con un conjunto de API y bastante específicamente incorrecto cuando se trabaja con Core Data.
En el contexto de trabajar con Mac OS X e iOS, siempre se debe tener en cuenta la seguridad de los hilos en el contexto del trabajo con las API del sistema. Incluso al usar, por ejemplo, un NSArray, significa que está trabajando con las API del sistema.
O en general ¿Qué es "no thread safe"?
Una API no segura para subprocesos es una API donde no puede interactuar con la API desde varios subprocesos simultáneamente. También puede haber restricciones adicionales que con mayor frecuencia implican el hilo principal. Por ejemplo, casi todas las operaciones de dibujo deben ocurrir en el hilo principal tanto en Mac OS X como en iOS.
La documentación de Apple asume que la seguridad del hilo es el caso excepcional. Es decir, una API solo es segura para subprocesos si la documentación afirma explícitamente seguridad de subprocesos. Si no se menciona la seguridad de subprocesos, debe suponer que la API no es segura para subprocesos.
En Obj-C, ¿qué significa en términos simples ; "CoreData no es seguro para subprocesos"
Esa afirmación no es del todo correcta, pero es una suposición segura.
En el caso de Core Data, el comportamiento de interacción del hilo es extremely well documented.
En resumen, algunas partes de la API son seguras para la ejecución de subprocesos (el coordinador de tienda, por ejemplo) y las piezas son bastante explícitas y no son seguras para subprocesos. Mientras que el MOC proporciona métodos de bloqueo y desbloqueo, puede puede también usar bloqueo externo. Pero no lo hagas Será menos eficiente y más frágil; significativamente así. En general, tampoco use el bloqueo interno. CoreData está optimizado en torno a tener un contexto por hilo/cola.
(Respuesta fijo basado en la retroalimentación de TC. Gracias.)
3
ACTUALIZACIÓN | Por favor, vea la respuesta de @ bbum. Acepto que mi respuesta es incorrecta y que @bbum es correcto.
Si algo se describe como "no seguro para subprocesos", significa que no se tomaron precauciones especiales para evitar que se bloquee si dos subprocesos independientes intentan usarlo simultáneamente. En general, el código que debe ser utilizado por más de un hilo requiere bloqueos explícitos (o bloques @synchronize) envolviendo aspectos del código. En particular, cualquier objeto/variable que se modifique casi seguramente causará un bloqueo si dos hilos pasaron a escribir en él al mismo tiempo (ya que estarían escribiendo en la misma dirección de memoria). Del mismo modo, si un hilo estaba leyendo una variable mientras otro le escribía, se devolvería la basura y el programa probablemente se bloquee.
El uso de @synchronized, o NSLock o un mutex POSIX, etc., garantiza que solo un hilo pueda ejecutar un bloque de código en particular en un momento dado. Los otros hilos se bloquean y tienen que esperar hasta que se libere el bloqueo. Hay un pequeño golpe de rendimiento con el uso de bloqueos (y por supuesto algunos gastos generales de desarrollo al tener que pensar en ellos), por lo que a menudo el código declara expresamente que no es seguro para subprocesos, por lo que usted, el que adoptó el código, coloca bloqueos según sea necesario. (o limite la ejecución del hilo no seguro a un único hilo).
Consulte la documentación de Apple para obtener más información sobre el roscado y el hilo de seguridad:
+4
* El uso de @synchronized o NSLock o una POSIX mutex etc, asegura que sólo un hilo puede ejecutar un bloque de código en particular en un momento dado. * En el contexto de la pregunta es ** completamente incorrecto **. ¡No puedes usar ninguna cantidad de bloqueo para asegurarte de que una API insegura para hilos se convierte en segura para hilos! – bbum
+1
El problema, más específicamente, es que cualquiera de estos solo garantiza que el bloque * that * solo se ejecute en un hilo a la vez. No garantiza nada sobre ningún * otro * bloque que también pueda usar la API insegura. Si dos partes diferentes de tu programa -o tu programa y la implementación de otra API que usas- acceden a la API insegura, suceden cosas malas sin importar cuántos bloqueos pongas. –
+0
Gracias chicos, ciertamente he aprendido algo aquí. @hmthur debería aceptar la respuesta de @ bbum en su lugar. – d11wtq
Cuestiones relacionadas
- 1. ¿Por qué este código no es seguro para subprocesos?
- 2. Enum.TryParse - ¿es seguro para subprocesos?
- 3. ¿Qué se entiende por WS- *?
- 4. ¿Es itertools seguro para subprocesos?
- 5. Log4Net FileAppender no es seguro para subprocesos?
- 6. ¿Qué se entiende por inmutable?
- 7. ¿Es PHP seguro para subprocesos?
- 8. ¿Para qué no es seguro para hilos?
- 9. ¿HttpContext.Current.Cache es seguro para subprocesos?
- 10. ¿Stream.Write es seguro para subprocesos?
- 11. NSTimer ¿es seguro para subprocesos?
- 12. ¿PrintWriter es seguro para subprocesos?
- 13. ¿SQLite.Net es seguro para subprocesos?
- 14. ¿Es System.ServiceModel.Channels.BufferManager seguro para subprocesos?
- 15. ¿SecureRandom es seguro para subprocesos?
- 16. ¿DWScript es seguro para subprocesos?
- 17. EventAggregator, ¿es seguro para subprocesos?
- 18. ¿MongoDB es seguro para subprocesos?
- 19. Por qué este código es reentrante pero no es seguro para subprocesos
- 20. malloc() no es reentrante pero es seguro para subprocesos?
- 21. ¿Por qué la lectura no es segura para subprocesos?
- 22. ¿Por qué llamar a una expresión lambda de Python desde C# no es seguro para subprocesos?
- 23. ¿Es TimeZone de Java seguro para subprocesos?
- 24. ¿Por qué este código de construcción singleton NO es seguro para subprocesos?
- 25. Boost math (función ibeta_inv) ¿no es seguro para subprocesos?
- 26. ¿Qué se entiende por el término "Instrumentación"?
- 27. ¿Qué se entiende por tipo parametrizado?
- 28. guava-libraries: ¿es Iterators.cycle() seguro para subprocesos?
- 29. ¿Qué se entiende por deshabilitar las interrupciones?
- 30. ¿Está leyendo un doble que no es seguro para subprocesos?
NSArray no dice explícitamente que sea seguro para los hilos, al menos no en la documentación de la clase en http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSArray_Class/NSArray.html y, sin embargo, es bastante común utilizar un NSMutableArray con un NSLock para proteger el acceso a él mediante varios subprocesos. ¿No es esto un uso "seguro"? – Dad
NSArray es un caso de frontera; * técnicamente * ninguna cantidad de bloqueo lo hará seguro. * Realísticamente * la implementación está aislada hasta el punto de que la encapsulación de bloqueo es "lo suficientemente segura". El problema, sin embargo, es que debe asegurarse de que ** cada invocación de método ** en esa matriz esté detrás de sus bloqueos; no puede dejar que la matriz escape al código de la estructura, por ejemplo. – bbum
Curiosamente, la palabra "hilo" no aparece en "Guía de programación de colecciones" (http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Collections/Collections.html%23// apple_ref/doc/uid/10000034i) y "seguro" solo aparece una vez y está hablando de enumeración y modificación de la colección durante la enumeración (no es seguro). – Dad