Jak czekać na zakończenie asynchronicznie wysłanego bloku?

Testuję kod, który wykonuje przetwarzanie asynchroniczne przy użyciu Grand Central Dispatch. Kod testowy wygląda następująco:

[object runSomeLongOperationAndDo:^{
    STAssert…
}];

Testy muszą czekać na zakończenie operacji. Moje obecne rozwiązanie wygląda następująco:

__block BOOL finished = NO;
[object runSomeLongOperationAndDo:^{
    STAssert…
    finished = YES;
}];
while (!finished);

Co wygląda nieco prymitywnie, znasz lepszy sposób? Mogę odsłonić kolejkę, a następnie zablokować, wywołując dispatch_sync:

[object runSomeLongOperationAndDo:^{
    STAssert…
}];
dispatch_sync(object.queue, ^{});

… Ale to może wystawiać zbyt wiele na object.

Próbuję użyć dispatch_semaphore. Powinno to wyglądać mniej więcej tak:

dispatch_semaphore_t sema = dispatch_semaphore_create(0);

[object runSomeLongOperationAndDo:^{
    STAssert…

    dispatch_semaphore_signal(sema);
}];

if (![NSThread isMainThread]) {
    dispatch_semaphore_wait(sema, DISPATCH_TIME_FOREVER);
} else {
    while (dispatch_semaphore_wait(sema, DISPATCH_TIME_NOW)) { 
        [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate dateWithTimeIntervalSinceNow:0]]; 
    }
}

Powinno to działać poprawnie, nawet jeśli runSomeLongOperationAndDo:uzna, że ​​operacja nie jest wystarczająco długa, aby zasłużyć na wątek, i zamiast tego działa synchronicznie.

Oprócz techniki semaforów omówionej wyczerpująco w innych odpowiedziach, możemy teraz używać XCTest w Xcode 6 do wykonywania testów asynchronicznych za pośrednictwem XCTestExpectation. Eliminuje to konieczność stosowania semaforów podczas testowania kodu asynchronicznego. Na przykład:

- (void)testDataTask
{
    XCTestExpectation *expectation = [self expectationWithDescription:@"asynchronous request"];

    NSURL *url = [NSURL URLWithString:@"http://www.apple.com"];
    NSURLSessionTask *task = [self.session dataTaskWithURL:url completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) {
        XCTAssertNil(error, @"dataTaskWithURL error %@", error);

        if ([response isKindOfClass:[NSHTTPURLResponse class]]) {
            NSInteger statusCode = [(NSHTTPURLResponse *) response statusCode];
            XCTAssertEqual(statusCode, 200, @"status code was not 200; was %d", statusCode);
        }

        XCTAssert(data, @"data nil");

        // do additional tests on the contents of the `data` object here, if you want

        // when all done, Fulfill the expectation

        [expectation fulfill];
    }];
    [task resume];

    [self waitForExpectationsWithTimeout:10.0 handler:nil];
}

Ze względu na przyszłych czytelników, chociaż technika semafora wysyłki jest cudowną techniką, gdy jest absolutnie potrzebna, muszę przyznać, że widzę zbyt wielu nowych programistów, niezaznajomionych z dobrymi wzorcami programowania asynchronicznego, zbyt szybko przechodzą na semafory jako ogólny mechanizm tworzenia asynchronicznych procedury zachowują się synchronicznie. Co gorsza, wielu z nich korzysta z tej techniki semaforów z głównej kolejki (i nigdy nie powinniśmy blokować głównej kolejki w aplikacjach produkcyjnych).

Wiem, że tak nie jest w tym przypadku (kiedy to pytanie zostało opublikowane, nie było takiego fajnego narzędzia XCTestExpectation; również w tych zestawach testowych musimy upewnić się, że test nie zakończy się, dopóki nie zostanie wykonane wywołanie asynchroniczne). Jest to jedna z tych rzadkich sytuacji, w których może być konieczna technika semaforów do blokowania głównego wątku.

Dlatego przepraszam autora tego oryginalnego pytania, dla którego technika semafora jest dobra, piszę to ostrzeżenie do wszystkich nowych programistów, którzy widzą tę technikę semaforów i rozważają zastosowanie jej w kodzie jako ogólnego podejścia do radzenia sobie z asynchronicznym metody: Ostrzegamy, że dziewięć razy na dziesięć technika semaforów jest nienajlepsze podejście w przypadku operacji asynchronicznych. Zamiast tego zapoznaj się z wzorcami blokowania / zamykania, a także wzorcami i powiadomieniami protokołu delegowania. Są to często znacznie lepsze sposoby radzenia sobie z zadaniami asynchronicznymi, niż używanie semaforów, aby zachowywały się synchronicznie. Zwykle istnieją dobre powody, dla których zadania asynchroniczne zostały zaprojektowane tak, aby zachowywały się asynchronicznie, więc należy stosować właściwy wzorzec asynchroniczny zamiast próbować je synchronizować.

Niedawno ponownie dołączyłem do tego problemu i napisałem o następującej kategorii NSObject :

@implementation NSObject (Testing)

- (void) performSelector: (SEL) selector
    withBlockingCallback: (dispatch_block_t) block
{
    dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);
    [self performSelector:selector withObject:^{
        if (block) block();
        dispatch_semaphore_signal(semaphore);
    }];
    dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
    dispatch_release(semaphore);
}

@end

W ten sposób mogę łatwo przekształcić połączenie asynchroniczne z oddzwanianiem w połączenie synchroniczne w testach:

[testedObject performSelector:@selector(longAsyncOpWithCallback:)
    withBlockingCallback:^{
    STAssert…
}];

Zasadniczo nie używaj żadnej z tych odpowiedzi, często się nie skalują (tu i tam są wyjątki, jasne)

Podejścia te są niezgodne ze sposobem, w jaki GCD ma działać, i doprowadzą do zablokowania i / lub zabicia baterii przez ciągłe odpytywanie.

Innymi słowy, należy zmienić kolejność kodu, tak aby nie było synchronicznego oczekiwania na wynik, ale zamiast tego radzić sobie z powiadomieniem wyniku o zmianie stanu (np. Wywołania zwrotne / protokoły delegowania, dostępność, odejście, błędy itp.). (Można je przekształcić w bloki, jeśli nie lubisz piekła zwrotnego.) Ponieważ w ten sposób możesz ujawnić realne zachowanie reszcie aplikacji, niż ukryć je za fałszywą fasadą.

Zamiast tego użyj NSNotificationCenter , zdefiniuj niestandardowy protokół delegowania z wywołaniami zwrotnymi dla swojej klasy. A jeśli nie lubisz tłumić wywołań zwrotnych delegatów, zawiń je w konkretną klasę proxy, która implementuje niestandardowy protokół i zapisuje różne właściwości bloku. Zapewne zapewnią również konstruktorów wygody.

Początkowa praca jest nieco większa, ale na dłuższą metę zmniejszy liczbę okropnych warunków wyścigowych i odpytywania o morderstwo baterii.

(Nie pytaj o przykład, ponieważ jest to trywialne i musieliśmy poświęcić czas na naukę podstaw celu c).

Oto sprytna sztuczka, która nie używa semafora:

dispatch_queue_t serialQ = dispatch_queue_create("serialQ", DISPATCH_QUEUE_SERIAL);
dispatch_async(serialQ, ^
{
    [object doSomething];
});
dispatch_sync(serialQ, ^{ });

To, co robisz, to czekanie przy użyciu dispatch_syncpustego bloku, aby Synchronicznie czekać w kolejce szeregowej wysyłki, aż do ukończenia bloku A-Synchronous.

- (void)performAndWait:(void (^)(dispatch_semaphore_t semaphore))perform;
{
  NSParameterAssert(perform);
  dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);
  perform(semaphore);
  dispatch_semaphore_wait(semaphore, DISPATCH_TIME_FOREVER);
  dispatch_release(semaphore);
}

Przykładowe użycie:

[self performAndWait:^(dispatch_semaphore_t semaphore) {
  [self someLongOperationWithSuccess:^{
    dispatch_semaphore_signal(semaphore);
  }];
}];

Istnieje również SenTestingKitAsync, który pozwala pisać kod w ten sposób:

- (void)testAdditionAsync {
    [Calculator add:2 to:2 block^(int result) {
        STAssertEquals(result, 4, nil);
        STSuccess();
    }];
    STFailAfter(2.0, @"Timeout");
}

(Szczegółowe informacje można znaleźć w artykule objc.io. ) A ponieważ Xcode 6 zawiera AsynchronousTestingkategorię, w XCTestktórej można pisać kod w ten sposób:

XCTestExpectation *somethingHappened = [self expectationWithDescription:@"something happened"];
[testedObject doSomethigAsyncWithCompletion:^(BOOL succeeded, NSError *error) {
    [somethingHappened fulfill];
}];
[self waitForExpectationsWithTimeout:1 handler:NULL];

Oto alternatywa dla jednego z moich testów:

__block BOOL success;
NSCondition *completed = NSCondition.new;
[completed lock];

STAssertNoThrow([self.client asyncSomethingWithCompletionHandler:^(id value) {
    success = value != nil;
    [completed lock];
    [completed signal];
    [completed unlock];
}], nil);    
[completed waitUntilDate:[NSDate dateWithTimeIntervalSinceNow:2]];
[completed unlock];
STAssertTrue(success, nil);

dispatch_semaphore_t sema = dispatch_semaphore_create(0);
[object blockToExecute:^{
    // ... your code to execute
    dispatch_semaphore_signal(sema);
}];

while (dispatch_semaphore_wait(semaphore, DISPATCH_TIME_NOW)) {
    [[NSRunLoop currentRunLoop]
        runUntilDate:[NSDate dateWithTimeIntervalSinceNow:0]];
}

Zrobiło to dla mnie.

Czasami pomocne są również pętle Timeout. Czy możesz poczekać, aż pojawi się jakiś (być może BOOL) sygnał z asynchronicznej metody wywołania zwrotnego, ale co, jeśli nie będzie żadnej odpowiedzi i chcesz wyjść z tej pętli? Poniżej znajduje się rozwiązanie, na które najczęściej odpowiedziano powyżej, ale z dodatkiem Limit czasu.

#define CONNECTION_TIMEOUT_SECONDS      10.0
#define CONNECTION_CHECK_INTERVAL       1

NSTimer * timer;
BOOL timeout;

CCSensorRead * sensorRead ;

- (void)testSensorReadConnection
{
    [self startTimeoutTimer];

    dispatch_semaphore_t sema = dispatch_semaphore_create(0);

    while (dispatch_semaphore_wait(sema, DISPATCH_TIME_NOW)) {

        /* Either you get some signal from async callback or timeout, whichever occurs first will break the loop */
        if (sensorRead.isConnected || timeout)
            dispatch_semaphore_signal(sema);

        [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode
                                 beforeDate:[NSDate dateWithTimeIntervalSinceNow:CONNECTION_CHECK_INTERVAL]];

    };

    [self stopTimeoutTimer];

    if (timeout)
        NSLog(@"No Sensor device found in %f seconds", CONNECTION_TIMEOUT_SECONDS);

}

-(void) startTimeoutTimer {

    timeout = NO;

    [timer invalidate];
    timer = [NSTimer timerWithTimeInterval:CONNECTION_TIMEOUT_SECONDS target:self selector:@selector(connectionTimeout) userInfo:nil repeats:NO];
    [[NSRunLoop currentRunLoop] addTimer:timer forMode:NSDefaultRunLoopMode];
}

-(void) stopTimeoutTimer {
    [timer invalidate];
    timer = nil;
}

-(void) connectionTimeout {
    timeout = YES;

    [self stopTimeoutTimer];
}

Bardzo prymitywne rozwiązanie problemu:

void (^nextOperationAfterLongOperationBlock)(void) = ^{

};

[object runSomeLongOperationAndDo:^{
    STAssert…
    nextOperationAfterLongOperationBlock();
}];

Swift 4:

Użyj synchronousRemoteObjectProxyWithErrorHandlerzamiast remoteObjectProxypodczas tworzenia obiektu zdalnego. Koniec z semaforem.

Poniższy przykład zwróci wersję otrzymaną od proxy. Bez synchronousRemoteObjectProxyWithErrorHandlertego nastąpi awaria (próba dostępu do niedostępnej pamięci):

func getVersion(xpc: NSXPCConnection) -> String
{
    var version = ""
    if let helper = xpc.synchronousRemoteObjectProxyWithErrorHandler({ error in NSLog(error.localizedDescription) }) as? HelperProtocol
    {
        helper.getVersion(reply: {
            installedVersion in
            print("Helper: Installed Version => \(installedVersion)")
            version = installedVersion
        })
    }
    return version
}

Muszę poczekać, aż UIWebView zostanie załadowany, zanim uruchomiłem moją metodę. Udało mi się to wykonać, wykonując kontrole gotowości UIWebView w głównym wątku za pomocą GCD w połączeniu z metodami semaforów wspomnianymi w tym wątku. Ostateczny kod wygląda następująco:

-(void)myMethod {

    if (![self isWebViewLoaded]) {

            dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);

            __block BOOL isWebViewLoaded = NO;

            dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{

                while (!isWebViewLoaded) {

                    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)((0.0) * NSEC_PER_SEC)), dispatch_get_main_queue(), ^{
                        isWebViewLoaded = [self isWebViewLoaded];
                    });

                    [NSThread sleepForTimeInterval:0.1];//check again if it's loaded every 0.1s

                }

                dispatch_sync(dispatch_get_main_queue(), ^{
                    dispatch_semaphore_signal(semaphore);
                });

            });

            while (dispatch_semaphore_wait(semaphore, DISPATCH_TIME_NOW)) {
                [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate dateWithTimeIntervalSinceNow:0]];
            }

        }

    }

    //Run rest of method here after web view is loaded

}