¿Cómo funciona @synchronized lock / unlock en Objective-C?

¿@Synchronized no utiliza "bloquear" y "desbloquear" para lograr la exclusión mutua? ¿Cómo se bloquea / desbloquea entonces?

La salida del siguiente programa es solo "Hello World".

@interface MyLock: NSLock<NSLocking>
@end

@implementation MyLock

- (id)init {
    return [super init];
}

- (void)lock {
    NSLog(@"before lock");
    [super lock];
    NSLog(@"after lock");
}

- (void)unlock {
    NSLog(@"before unlock");
    [super unlock];
    NSLog(@"after unlock");
}

@end


int main (int argc, const char * argv[]) {
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];

    MyLock *lock = [[MyLock new] autorelease];
    @synchronized(lock) {
        NSLog(@"Hello World");
    }

    [pool drain];
}

La sincronización de nivel de lenguaje Objective-C usa el mutex, al igual que NSLock hace. Semánticamente hay algunas pequeñas diferencias técnicas, pero es básicamente correcto pensar en ellas como dos interfaces separadas implementadas sobre una entidad común (más primitiva).

En particular con un NSLocktiene un bloqueo explícito mientras que con@synchronized que con un bloqueo implícito asociado con el objeto que está utilizando para sincronizar. El beneficio del bloqueo de nivel de lenguaje es que el compilador lo comprende para que pueda lidiar con problemas de alcance, pero mecánicamente se comportan básicamente igual.

Puedes pensar @synchronizedcomo una reescritura del compilador:

- (NSString *)myString {
  @synchronized(self) {
    return [[myString retain] autorelease];
  }
}

se transforma en:

- (NSString *)myString {
  NSString *retval = nil;
  pthread_mutex_t *self_mutex = LOOK_UP_MUTEX(self);
  pthread_mutex_lock(self_mutex);
  retval = [[myString retain] autorelease];
  pthread_mutex_unlock(self_mutex);
  return retval;
}

Eso no es exactamente correcto porque la transformación real es más compleja y usa bloqueos recursivos, pero debería transmitir el punto.

En Objective-C, un @synchronizedbloque maneja el bloqueo y desbloqueo (así como las posibles excepciones) automáticamente para usted. El tiempo de ejecución genera dinámicamente un NSRecursiveLock asociado con el objeto con el que está sincronizando. Esta documentación de Apple lo explica con más detalle. Es por eso que no está viendo los mensajes de registro de su subclase NSLock: el objeto en el que sincroniza puede ser cualquier cosa, no solo un NSLock.

Básicamente, @synchronized (...)es una construcción conveniente que simplifica su código. Al igual que la mayoría de las abstracciones simplificadoras, tiene gastos generales asociados (piense en ello como un costo oculto), y es bueno ser consciente de eso, pero el rendimiento bruto probablemente no sea el objetivo supremo cuando se usan tales construcciones de todos modos.

Realmente

{
  @synchronized(self) {
    return [[myString retain] autorelease];
  }
}

se transforma directamente en:

// needs #import <objc/objc-sync.h>
{
  objc_sync_enter(self)
    id retVal = [[myString retain] autorelease];
  objc_sync_exit(self);
  return retVal;
}

Esta API disponible desde iOS 2.0 e importada usando ...

#import <objc/objc-sync.h>

La implementación de Apple de @synchronized es de código abierto y se puede encontrar aquí . Mike ash escribió dos publicaciones realmente interesantes sobre este tema:

• Cerraduras, seguridad de roscas y Swift
• Vamos a construir @ sincronizado

En pocas palabras, tiene una tabla que asigna punteros de objetos (usando sus direcciones de memoria como claves) a pthread_mutex_tbloqueos, que se bloquean y desbloquean según sea necesario.

Simplemente asocia un semáforo con cada objeto, y lo usa.