W jaki sposób @synchronizowane blokowanie / odblokowywanie w Objective-C?

Czy @synchronized nie używa „blokady” i „odblokowania” do osiągnięcia wzajemnego wykluczenia? Jak to się wtedy blokuje / odblokowuje?

Wyjście następującego programu to tylko „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];
}

Synchronizacja na poziomie języka Objective-C wykorzystuje mutex, podobnie jak NSLockrobi to. Semantycznie istnieją pewne niewielkie różnice techniczne, ale zasadniczo poprawne jest myślenie o nich jako o dwóch oddzielnych interfejsach zaimplementowanych na wspólnej (bardziej prymitywnej) jednostce.

W szczególności NSLockmasz blokadę jawną, podczas gdy @synchronizedmasz ukrytą blokadę związaną z obiektem, którego używasz do synchronizacji. Zaletą blokowania na poziomie języka jest to, że kompilator to rozumie, więc może poradzić sobie z problemami z zakresu, ale mechanicznie zachowują się w zasadzie tak samo.

Możesz pomyśleć o @synchronizedprzepisaniu kompilatora:

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

przekształca się w:

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

Nie jest to do końca poprawne, ponieważ rzeczywista transformacja jest bardziej złożona i korzysta z blokad rekurencyjnych, ale powinna mieć sens.

W Objective-C @synchronizedblok obsługuje automatycznie blokowanie i odblokowywanie (a także możliwe wyjątki). Środowisko wykonawcze dynamicznie generuje NSRecursiveLock, który jest powiązany z obiektem, na którym synchronizujesz. Ta dokumentacja Apple wyjaśnia to bardziej szczegółowo. Dlatego nie widzisz komunikatów dziennika z podklasy NSLock - obiekt, na którym synchronizujesz może być czymkolwiek, nie tylko NSLock.

Zasadniczo @synchronized (...)jest to wygodna konstrukcja, która usprawnia kod. Jak większość uproszczonych abstrakcji, wiąże się to z narzutem (pomyśl o tym jako o ukrytym koszcie) i dobrze jest o tym wiedzieć, ale surowa wydajność prawdopodobnie nie jest najważniejszym celem przy stosowaniu takich konstrukcji.

Tak właściwie

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

przekształca się bezpośrednio w:

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

Ten interfejs API jest dostępny od iOS 2.0 i importowany przy użyciu ...

#import <objc/objc-sync.h>

Implementacja @synchronized przez Apple jest oprogramowaniem typu open source i można go znaleźć tutaj . Mike Ash napisał dwa naprawdę interesujące posty na ten temat:

• Zamki, bezpieczeństwo wątków i szybkie
• Zbudujmy @synchronized

W skrócie ma tabelę, która mapuje wskaźniki obiektów (używając ich adresów pamięci jako kluczy) na pthread_mutex_tblokady, które są blokowane i odblokowywane w razie potrzeby.

Po prostu łączy semafor z każdym obiektem i używa go.