ios - grand - swift thread

Diferencias @synchronized() y NSLock

Question

Tengo un bloque de código al que se accede con frecuencia y desde el hilo principal o varios otros hilos de fondo. Necesito asegurarme de que este código solo se procesa de uno en uno.

Actualmente estoy usando un @synchronized(self) { } pero no estoy seguro de si está proporcionando la protección correcta. ¿En qué se diferencia de una instancia de NSLock ?

Finalmente, ¿alguien puede sugerir cómo puedo proteger mi método? El método está en mi delegado de solicitud, y accedo a él desde varios subprocesos llamando:

[[[UIApplication sharedApplication] delegate] myMethod];

Muchas gracias,

Micro

Answer 1

Hay una excelente publicación en el blog de Google Mac sobre el funcionamiento interno de @synchronized :
http://googlemac.blogspot.com/2006/10/synchronized-swimming.html

Actualmente estoy usando un bloque @synchronized (self) {} pero no estoy seguro de si está proporcionando la protección correcta. ¿En qué se diferencia de una instancia de NSLock?

Hay varias formas de sincronizar secciones críticas ( @synchronized, NSLock, OSSpinLock, ... ).
Creo que @synchronized es el @synchronized más conveniente ( y también el más lento ).
Aquí hay una buena respuesta SO que explica las diferencias entre @synchronized y NSLock.

Usted está accediendo a su método a través de un delegado de instancias compartidas (que básicamente es un singleton). Tal vez pueda reconsiderar su diseño y encontrar una forma que le permita bloquear un fragmento de código más pequeño dentro de mi myMethod .

Answer 2

Si realmente tiene algo que desea que se procese un elemento a la vez, mi recomendación es usar NSOperations y un NSOperationQueue donde haya establecido el maxConcurrentOperationCount en 1. Si se asegura de que la única forma en que este bloque compartido de el código al que se accede es a través de las operaciones en esta cola, usted eliminará la necesidad de costosos bloqueos.

Esto puede requerir una pequeña reorganización de su aplicación, pero he descubierto que aplicar esto dentro de mis propias aplicaciones ha dado lugar a un mejor rendimiento y un código más limpio.