Bloquear un objeto para que no sea accedido por varios subprocesos - Objective-C

Question

Tengo una pregunta con respecto a la seguridad de subprocesos en Objective-C. He leído un par de otras respuestas, alguna de la documentación de Apple, y todavía tengo algunas dudas con respecto a esto, así que pensé en hacer mi propia pregunta.

Mi pregunta es triple:

Supongamos que tengo una matriz, NSMutableArray *myAwesomeArray;

Fold 1:

Ahora me corrija si estoy equivocado, pero por lo que entiendo , utilizando @synchronized(myAwesomeArray){...} evitará que dos subprocesos accedan al mismo bloque de código. Así que, básicamente, si tengo algo como:

-(void)doSomething { 
    @synchronized(myAwesomeArray) { 
     //some read/write operation on myAwesomeArray 
    } 
} 

entonces, si dos subprocesos tienen acceso a la mismo método en el momento misma, ese bloque de código se hilo de seguridad. Supongo que he entendido esta parte correctamente.

Fold 2:

¿Qué hago si se está accediendo myAwesomeArray por múltiples hilos de diferentes métodos? Si tengo algo como:

- (void)readFromArrayAccessedByThreadOne { 
    //thread 1 reads from myAwesomeArray 
} 

- (void)writeToArrayAccessedByThreadTwo { 
    //thread 2 writes to myAwesomeArray 
} 

Ahora, tanto los métodos se accede por dos hilos diferentes al mismo tiempo. ¿Cómo me aseguro de que myAwesomeArray no tenga problemas? ¿Utilizo algo como NSLock o NSRecursiveLock?

Fold 3:

Ahora, en los dos casos anteriores, myAwesomeArray era un Ivar en la memoria. ¿Qué ocurre si tengo un archivo de base de datos que no siempre guardo en la memoria? Creo un databaseManagerInstance cada vez que quiero realizar operaciones de bases de datos, y lo libero una vez que termino. Por lo tanto, básicamente, diferentes clases pueden acceder a la base de datos. Cada clase crea su propia instancia de DatabaseManger, pero básicamente, todas usan el mismo archivo de base de datos. ¿Cómo me aseguro de que los datos no estén dañados debido a las condiciones de carrera en una situación así?

Esto me ayudará a aclarar algunos de mis fundamentos.

Answer 1

Fold 1 Por lo general, su comprensión de lo que @synchronized hace es correcta. Sin embargo, técnicamente, no hace ningún código "thread-safe". Impide que diferentes hilos soliciten el mismo bloqueo al mismo tiempo, sin embargo, debe asegurarse de usar siempre el mismo token de sincronización al realizar secciones críticas. Si no lo haces, aún puedes encontrarte en la situación en la que dos hilos realizan secciones críticas al mismo tiempo. Check the docs.

Fold 2 La mayoría de las personas probablemente te aconsejarían usar NSRecursiveLock. Si yo fuera tú, usaría GCD. Here is a great document showing how to migrate from thread programming to GCD programming, creo que este enfoque al problema es mucho mejor que el basado en NSLock. En pocas palabras, crea una cola en serie y envía sus tareas a esa cola. De esta forma, se asegura de que sus secciones críticas se manejen en serie, por lo que solo se realiza una sección crítica en un momento determinado.

Fold 3 Esto es lo mismo que Fold 2, sólo que más específico. La base de datos es un recurso, de muchas maneras es lo mismo que la matriz o cualquier otra cosa. If you want to see the GCD based approach in database programming context, take a look at fmdb implementation. Hace exactamente lo que describí en Fold2.

Como nota al margen de Fold 3, no creo que una instancia de DatabaseManager cada vez que desee utilizar la base de datos y luego soltarlo es el enfoque correcto. Creo que deberías crear una única conexión de base de datos y conservarla a través de tu sesión de aplicación. De esta forma, es más fácil de administrar. Nuevamente, fmdb es un gran ejemplo de cómo se puede lograr esto.

Editar Si no desea usar GCD entonces sí, tendrá que utilizar algún tipo de mecanismo de bloqueo, y sí, NSRecursiveLock evitará estancamientos si utiliza la recursividad en sus métodos, por lo que es una buena opción (es usado por @synchronized). Sin embargo, puede haber una captura. Si es posible que muchos subprocesos esperen el mismo recurso y el orden en el que obtienen acceso sea relevante, NSRecursiveLock no es suficiente. Todavía puede manejar esta situación con NSCondition, pero créame, ahorrará mucho tiempo usando GCD en este caso. Si el orden de los hilos no es relevante, estás a salvo con bloqueos.

Answer 2

Subclase NSMutable Arregle para proporcionar el bloqueo de los métodos de acceso (lectura y escritura). Algo como:

@interface MySafeMutableArray : NSMutableArray { NSRecursiveLock *lock; } @end 

@implementation MySafeMutableArray 

- (void)addObject:(id)obj { 
    [self.lock lock]; 
    [super addObject: obj]; 
    [self.lock unlock]; 
} 

// ... 
@end 

Este enfoque encapsula el bloqueo como parte de la matriz. Los usuarios no necesitan cambiar sus llamadas (pero deben tener en cuenta que podrían bloquear/esperar el acceso si el acceso es de tiempo crítico). Una ventaja importante de este enfoque es que si decide que prefiere no utilizar bloqueos, puede volver a implementar MySafeMutableArray para usar las colas de envío, o lo que sea mejor para su problema específico. Por ejemplo, se podría implementar addObject como:

- (void)addObject:(id)obj { 
    dispatch_sync (self.queue, ^{ [super addObject: obj] }); 
} 

Nota: si el uso de bloqueos, seguramente necesitará NSRecursiveLock, no NSLock, porque no se sabe de las implementaciones de Objective-C de addObject, etc, son ellos mismos recursivo

Answer 3

Como en Swift 3 en WWDC 2016 Session Session 720 Concurrent Programming With GCD in Swift 3, se debe utilizar queue

class MyObject { 
    private let internalState: Int 
    private let internalQueue: DispatchQueue 

    var state: Int { 
    get { 
     return internalQueue.sync { internalState } 
    } 

    set (newValue) { 
     internalQueue.sync { internalState = newValue } 
    } 
    } 
}