Como espero que um bloco despachado de forma assíncrona termine?

Estou testando algum código que faz processamento assíncrono usando o Grand Central Dispatch. O código de teste fica assim:

[object runSomeLongOperationAndDo:^{
    STAssert…
}];

Os testes precisam aguardar a conclusão da operação. Minha solução atual é assim:

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

O que parece um pouco bruto, você conhece uma maneira melhor? Eu poderia expor a fila e depois bloquear chamando dispatch_sync:

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

... mas isso talvez exponha muito o object.

Tentando usar a dispatch_semaphore. Deve ser algo como isto:

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

Isso deve se comportar corretamente, mesmo que runSomeLongOperationAndDo:decida que a operação não é realmente longa o suficiente para merecer threading e é executada de forma síncrona.

Além da técnica do semáforo abordada exaustivamente em outras respostas, agora podemos usar o XCTest no Xcode 6 para executar testes assíncronos via XCTestExpectation. Isso elimina a necessidade de semáforos ao testar código assíncrono. Por exemplo:

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

Para o bem dos futuros leitores, embora a técnica de semáforo de expedição seja uma técnica maravilhosa quando absolutamente necessária, devo confessar que vejo muitos desenvolvedores novos, não familiarizados com bons padrões de programação assíncronos, gravitando muito rapidamente em semáforos como um mecanismo geral para tornar assíncrona rotinas se comportam de forma síncrona. Pior, já vi muitos deles usarem essa técnica de semáforo na fila principal (e nunca devemos bloquear a fila principal nos aplicativos de produção).

Sei que esse não é o caso aqui (quando esta pergunta foi publicada, não havia uma ferramenta interessante como XCTestExpectation; também, nesses conjuntos de testes, devemos garantir que o teste não termine até que a chamada assíncrona seja concluída). Essa é uma daquelas situações raras em que a técnica de semáforo para bloquear o encadeamento principal pode ser necessária.

Portanto, com minhas desculpas ao autor desta pergunta original, para quem a técnica de semáforo é sólida, escrevo este aviso a todos os novos desenvolvedores que veem essa técnica de semáforo e considero aplicá-la em seu código como uma abordagem geral para lidar com assinaturas assíncronas. métodos: esteja avisado que nove em cada dez vezes, a técnica do semáforo não éa melhor abordagem ao contar operações assíncronas. Em vez disso, familiarize-se com os padrões de bloqueio / fechamento de conclusão, bem como com padrões e notificações de protocolo de delegação. Geralmente, essas são maneiras muito melhores de lidar com tarefas assíncronas, em vez de usar semáforos para fazê-las se comportar de maneira síncrona. Geralmente, existem boas razões para as tarefas assíncronas terem sido projetadas para se comportarem de maneira assíncrona, portanto, use o padrão assíncrono correto, em vez de tentar fazê-las se comportar de maneira síncrona.

Recentemente, vim a esse problema novamente e escrevi a seguinte categoria em 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

Dessa forma, posso facilmente transformar chamadas assíncronas com retorno de chamada em síncronas nos testes:

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

Geralmente, não use nenhuma dessas respostas, elas geralmente não serão dimensionadas (há exceções aqui e ali, com certeza)

Essas abordagens são incompatíveis com a forma como o GCD se destina a funcionar e acabam causando conflitos e / ou morte da bateria por meio de pesquisas ininterruptas.

Em outras palavras, reorganize seu código para que não haja espera síncrona por um resultado, mas lide com um resultado sendo notificado de alteração de estado (por exemplo, retornos de chamada / protocolos de delegados, disponibilidade, partida, erros, etc.). (Eles podem ser refatorados em blocos se você não gostar do inferno de retorno de chamada.) Como é assim, expor o comportamento real ao restante do aplicativo e ocultá-lo atrás de uma fachada falsa.

Em vez disso, use o NSNotificationCenter , defina um protocolo de delegação personalizado com retornos de chamada para sua classe. E se você não gosta de mexer com os retornos de chamada delegados, envolva-os em uma classe proxy concreta que implemente o protocolo personalizado e salve os vários blocos nas propriedades. Provavelmente também fornece construtores de conveniência também.

O trabalho inicial é um pouco mais alto, mas reduzirá o número de péssimas condições de corrida e pesquisas sobre bateria a longo prazo.

(Não peça um exemplo, porque é trivial e também tivemos que investir tempo para aprender o básico do objetivo-c.)

Aqui está um truque bacana que não usa um semáforo:

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

O que você faz é esperar o uso dispatch_synccom um bloco vazio para aguardar de forma síncrona em uma fila de expedição serial até que o bloco A-Synchronous seja concluído.

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

Exemplo de uso:

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

Há também o SenTestingKitAsync que permite escrever código como este:

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

(Veja o artigo objc.io para obter detalhes.) E como o Xcode 6 existe uma AsynchronousTestingcategoria XCTestque permite escrever códigos como este:

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

Aqui está uma alternativa de um dos meus testes:

__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]];
}

Isso fez por mim.

Às vezes, os loops de tempo limite também são úteis. Você pode esperar até receber algum sinal (pode ser BOOL) do método de retorno de chamada assíncrono, mas e se não houver resposta alguma e quiser sair desse loop? Aqui abaixo está a solução, mais respondida acima, mas com uma adição de Timeout.

#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];
}

Solução muito primitiva para o problema:

void (^nextOperationAfterLongOperationBlock)(void) = ^{

};

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

Swift 4:

Use em synchronousRemoteObjectProxyWithErrorHandlervez de remoteObjectProxyao criar o objeto remoto. Não há mais necessidade de um semáforo.

O exemplo abaixo retornará a versão recebida do proxy. Sem o synchronousRemoteObjectProxyWithErrorHandlertravamento (tentando acessar a memória não acessível):

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
}

Eu tenho que esperar até que um UIWebView seja carregado antes de executar meu método. Consegui fazê-lo executando verificações prontas do UIWebView no thread principal usando o GCD em combinação com os métodos de semáforo mencionados neste thread. O código final fica assim:

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

}