W jaki sposób @synchronized lock/unlock w Objective-C?

Question

Czy @synchronized nie używa "blokady" i "odblokowania", aby osiągnąć wzajemne wykluczenie? Jak działa blokowanie/odblokowywanie?

Dane wyjściowe tego 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]; 
} 

Answer 1

Synchronizacja poziomu języka Objective-C używa muteksu, tak jak robi to NSLock. Semantycznie istnieją pewne niewielkie różnice techniczne, ale zasadniczo słusznie jest myśleć o nich jako o dwóch oddzielnych interfejsach zaimplementowanych na szczycie wspólnego (bardziej prymitywnego) bytu.

W szczególności z NSLock masz jawną blokadę, natomiast przy @synchronized masz niejawną blokadę powiązaną z obiektem, którego używasz do synchronizacji. Zaletą blokowania na poziomie języka jest to, że kompilator ją rozumie, aby poradzić sobie z problemami z zakresu, ale mechanicznie zachowują się w zasadzie tak samo.

Można myśleć o @synchronized jako przepisanie kompilatora:

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

przekształca się:

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

To nie jest do końca poprawne, ponieważ rzeczywista przekształcać jest bardziej złożona i używa rekurencyjnych zamki, ale powinno to mieć sens.

Answer 2

Po prostu kojarzy semafor z każdym obiektem i używa go.

Answer 3

W Objective-C blok @synchronized automatycznie obsługuje blokowanie i odblokowywanie (jak również możliwe wyjątki). Środowisko wykonawcze dynamicznie generuje w zasadzie blok NSRecursiveLock, który jest powiązany z obiektem, który jest synchronizowany. This Apple documentation wyjaśnia to bardziej szczegółowo. Dlatego nie widzisz komunikatów logów z podklasy NSLock - obiekt, na którym synchronizujesz, może być czymkolwiek, a nie tylko NSLockiem.

Zasadniczo @synchronized (...) jest konstruktem wygoda który usprawnia swój kod. Podobnie jak większość upraszczających abstrakcji, wiąże się ona z kosztami ogólnymi (myślę, że jest to ukryty koszt), i dobrze jest być tego świadomym, ale surowa wydajność prawdopodobnie nie jest nadrzędnym celem przy stosowaniu takich konstrukcji.

Answer 4

Właściwie

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

przekształca się bezpośrednio do:

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

tego API dostępny od iOS 2.0 i importować za pomocą ...

#import <objc/objc-sync.h> 

Answer 5

realizacja Apple z @synchronized jest open source i można go znaleźć here.Popiół Mike napisał dwa bardzo ciekawy post na ten temat:

• Locks, Thread Safety, and Swift
• Let's Build @synchronized

w pigułce ma tabelę mapy sprzeciwu wskaźniki (przy użyciu ich adresów pamięci jako klucze) do pthread_mutex_t zamków , które są blokowane i odblokowywane w razie potrzeby.