Come funziona il blocco / sblocco sincronizzato di @ in Objective-C?

@Synchronized non utilizza "lock" e "unlock" per ottenere l'esclusione reciproca? Come si blocca / sblocca quindi?

L'output del seguente programma è 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 sincronizzazione a livello di linguaggio Objective-C utilizza il mutex, proprio come NSLockfa. Semanticamente ci sono alcune piccole differenze tecniche, ma è fondamentalmente corretto pensarle come due interfacce separate implementate su un'entità comune (più primitiva).

In particolare con a NSLockhai un blocco esplicito mentre con @synchronizedte hai un blocco implicito associato all'oggetto che stai usando per sincronizzare. Il vantaggio del blocco a livello di lingua è che il compilatore lo comprende in modo da poter gestire i problemi di scoping, ma meccanicamente si comportano sostanzialmente allo stesso modo.

Puoi pensare @synchronizeda una riscrittura del compilatore:

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

si trasforma in:

- (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;
}

Ciò non è esattamente corretto perché la trasformazione effettiva è più complessa e utilizza blocchi ricorsivi, ma dovrebbe ottenere il punto.

In Objective-C, un @synchronizedblocco gestisce automaticamente il blocco e lo sblocco (nonché eventuali eccezioni). Il runtime genera essenzialmente un NSRecursiveLock associato all'oggetto su cui si sta sincronizzando. Questa documentazione di Apple lo spiega in modo più dettagliato. Questo è il motivo per cui non vedi i messaggi di registro della tua sottoclasse NSLock: l'oggetto su cui sincronizzi può essere qualsiasi cosa, non solo un NSLock.

Fondamentalmente, @synchronized (...)è un costrutto pratico che semplifica il tuo codice. Come la maggior parte delle astrazioni semplificanti, ha un sovraccarico associato (pensalo come un costo nascosto), ed è bene esserne consapevoli, ma le prestazioni grezze non sono probabilmente l'obiettivo supremo quando si usano tali costrutti.

In realtà

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

si trasforma direttamente in:

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

Questa API è disponibile da iOS 2.0 e importata utilizzando ...

#import <objc/objc-sync.h>

L'implementazione di Apple di @synchronized è open source e può essere trovata qui . Mike Ash ha scritto due post davvero interessanti su questo argomento:

• Lucchetti, sicurezza del filo e Swift
• Costruiamo @sincronizzato

In breve ha una tabella che mappa i puntatori agli oggetti (usando i loro indirizzi di memoria come chiavi) ai pthread_mutex_tblocchi, che sono bloccati e sbloccati secondo necessità.

Associa solo un semaforo a ogni oggetto e lo usa.