Como o bloqueio / desbloqueio sincronizado no Objective-C?

@Synchronized não usa "lock" e "unlock" para obter exclusão mútua? Como ele bloqueia / desbloqueia então?

A saída do programa a seguir é apenas "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];
}

A sincronização no nível de linguagem Objective-C usa o mutex, assim como NSLockfaz. Semanticamente, existem algumas pequenas diferenças técnicas, mas é basicamente correto pensar nelas como duas interfaces separadas implementadas sobre uma entidade comum (mais primitiva).

Em particular, NSLockvocê tem um bloqueio explícito, enquanto @synchronizedque um bloqueio implícito está associado ao objeto que você está usando para sincronizar. O benefício do bloqueio no nível do idioma é que o compilador o entende para lidar com problemas de escopo, mas mecanicamente eles se comportam basicamente da mesma forma.

Você pode pensar @synchronizedem uma reescrita do compilador:

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

é transformado em:

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

Isso não é exatamente correto, porque a transformação real é mais complexa e usa bloqueios recursivos, mas deve passar o ponto.

No Objective-C, um @synchronizedbloco lida com o bloqueio e desbloqueio (bem como com possíveis exceções) automaticamente para você. O tempo de execução dinamicamente gera essencialmente um NSRecursiveLock associado ao objeto no qual você está sincronizando. Esta documentação da Apple explica mais detalhadamente. É por isso que você não está vendo as mensagens de log da sua subclasse NSLock - o objeto no qual você sincroniza pode ser qualquer coisa, não apenas um NSLock.

Basicamente, @synchronized (...)é uma construção de conveniência que otimiza seu código. Como a maioria das abstrações simplificadoras, ela tem sobrecarga associada (pense nisso como um custo oculto), e é bom estar ciente disso, mas o desempenho bruto provavelmente não é o objetivo supremo ao usar essas construções de qualquer maneira.

Na realidade

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

transforma diretamente em:

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

Esta API está disponível desde o iOS 2.0 e importada usando ...

#import <objc/objc-sync.h>

A implementação do @synchronized pela Apple é de código aberto e pode ser encontrada aqui . Mike ash escreveu dois posts realmente interessantes sobre esse assunto:

• Fechaduras, segurança de linha e Swift
• Vamos construir @synchronized

Em poucas palavras, há uma tabela que mapeia ponteiros de objetos (usando seus endereços de memória como chaves) para pthread_mutex_tbloqueios, que são bloqueados e desbloqueados conforme necessário.

Apenas associa um semáforo a cada objeto e o usa.