Comment le verrouillage / déverrouillage @synchronized dans Objective-C?

@Synchronized n'utilise-t-il pas "verrouiller" et "déverrouiller" pour réaliser l'exclusion mutuelle? Comment ça se verrouille / déverrouille alors?

La sortie du programme suivant est uniquement "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 synchronisation au niveau du langage Objective-C utilise le mutex, tout comme le NSLockfait. Sémantiquement, il existe de petites différences techniques, mais il est fondamentalement correct de les considérer comme deux interfaces distinctes implémentées au-dessus d'une entité commune (plus primitive).

En particulier avec un, NSLockvous avez un verrou explicite tandis qu'avec @synchronizedvous avez un verrou implicite associé à l'objet que vous utilisez pour synchroniser. L'avantage du verrouillage au niveau du langage est que le compilateur le comprend afin qu'il puisse traiter les problèmes de portée, mais mécaniquement, ils se comportent essentiellement de la même manière.

Vous pouvez penser @synchronizedà une réécriture du compilateur:

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

se transforme 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;
}

Ce n'est pas exactement correct car la transformation réelle est plus complexe et utilise des verrous récursifs, mais elle devrait faire passer le message.

Dans Objective-C, un @synchronizedbloc gère automatiquement le verrouillage et le déverrouillage (ainsi que les exceptions possibles). Le runtime génère dynamiquement essentiellement un NSRecursiveLock qui est associé à l'objet sur lequel vous effectuez la synchronisation. Cette documentation Apple l' explique plus en détail. C'est pourquoi vous ne voyez pas les messages de journal de votre sous-classe NSLock - l'objet sur lequel vous synchronisez peut être n'importe quoi, pas seulement un NSLock.

Fondamentalement, @synchronized (...)c'est une construction pratique qui rationalise votre code. Comme la plupart des abstractions simplificatrices, il a associé des frais généraux (pensez-y comme un coût caché), et il est bon d'en être conscient, mais les performances brutes ne sont probablement pas l'objectif suprême lors de l'utilisation de telles constructions de toute façon.

Réellement

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

se transforme directement en:

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

Cette API disponible depuis iOS 2.0 et importée en utilisant ...

#import <objc/objc-sync.h>

L'implémentation d'Apple de @synchronized est open source et vous pouvez la trouver ici . Mike Ash a écrit deux articles très intéressants sur ce sujet:

• Serrures, sécurité du fil et Swift
• Construisons @synchronized

En bref, il a une table qui mappe les pointeurs d'objets (en utilisant leurs adresses mémoire comme clés) sur les pthread_mutex_tverrous, qui sont verrouillés et déverrouillés selon les besoins.

Il associe simplement un sémaphore à chaque objet et l'utilise.