How do I wait for an asynchronously dispatched block to finish

Question

I am testing some code that does asynchronous processing using Grand Central Dispatch  The testing code looks like this    object runSomeLongOperationAndDo        STAssert          The tests have to wait for the operation to finish  My current solution looks like this     block BOOL finished   NO   object runSomeLongOperationAndDo        STAssert        finished   YES      while   finished     Which looks a bit crude  do you know a better way  I could expose the queue and then block by calling dispatch sync    object runSomeLongOperationAndDo        STAssert        dispatch sync object queue             but that   s maybe exposing too much on the object

User · Answer

Very primitive solution to the problem   void   nextOperationAfterLongOperationBlock  void             object runSomeLongOperationAndDo        STAssert        nextOperationAfterLongOperationBlock

User · Answer

I   ve recently come to this issue again and wrote the following category on 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   This way I can easily turn asynchronous call with a callback into a synchronous one in tests    testedObject performSelector  selector longAsyncOpWithCallback       withBlockingCallback        STAssert

User · Answer

I have to wait until a UIWebView is loaded before running my method  I was able to get this working by performing UIWebView ready checks on main thread using GCD in combination with semaphore methods mentioned in this thread  Final code looks like this   - 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

User · Answer

Here s a nifty trick that doesn t use a semaphore   dispatch queue t serialQ   dispatch queue create  serialQ   DISPATCH QUEUE SERIAL   dispatch async serialQ           object doSomething       dispatch sync serialQ           What you do is wait using dispatch sync with an empty block to Synchronously wait on a serial dispatch queue until the A-Synchronous block has completed

User · Answer

Sometimes  Timeout loops are also helpful  May you wait until you get some  may be BOOL  signal from async callback method  but what if no response ever  and you want to break out of that loop  Here below is solution  mostly answered above  but with an addition of 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

User · Answer

Trying to use a dispatch semaphore  It should look something like this   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               This should behave correctly even if runSomeLongOperationAndDo  decides that the operation isn t actually long enough to merit threading and runs synchronously instead

User · Answer

Here is an alternative from one of my tests     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

User · Answer

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        This did it for me

User · Answer

-  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       Example usage    self performAndWait   dispatch semaphore t semaphore       self someLongOperationWithSuccess        dispatch semaphore signal semaphore

User · Answer

Swift 4   Use synchronousRemoteObjectProxyWithErrorHandler instead of remoteObjectProxy when creating the remote object  No more need for a semaphore   Below example will return the version received from the proxy  Without the synchronousRemoteObjectProxyWithErrorHandler it will crash  trying to access non accessible memory    func getVersion xpc  NSXPCConnection  - gt  String       var version          if let helper   xpc synchronousRemoteObjectProxyWithErrorHandler   error in NSLog error localizedDescription     as  HelperProtocol               helper getVersion reply                installedVersion in             print  Helper  Installed Version   gt    installedVersion                version   installedVersion                      return version

User · Answer

Generally don t use any of these answers  they often won t scale   there s exceptions here and there  sure   These approaches are incompatible with how GCD is intended to work and will end up either causing deadlocks and or killing the battery by nonstop polling   In other words  rearrange your code so that there is no synchronous waiting for a result  but instead deal with a result being notified of change of state  eg callbacks delegate protocols  being available  going away  errors  etc      These can be refactored into blocks if you don t like callback hell    Because this is how to expose real behavior to the rest of the app than hide it behind a false fa  ade   Instead  use NSNotificationCenter  define a custom delegate protocol with callbacks for your class    And if you don t like mucking with delegate callbacks all over  wrap them into a concrete proxy class that implements the custom protocol and saves the various block in properties   Probably also provide convenience constructors as well   The initial work is slightly more but it will reduce the number of awful race-conditions and battery-murdering polling in the long-run    Don t ask for an example  because it s trivial and we had to invest the time to learn objective-c basics too

User · Answer

There   s also SenTestingKitAsync that lets you write code like this   -  void testAdditionAsync        Calculator add 2 to 2 block  int result            STAssertEquals result  4  nil           STSuccess                STFailAfter 2 0    Timeout         See objc io article for details   And since Xcode 6 there   s an AsynchronousTesting category on XCTest that lets you write code like this   XCTestExpectation  somethingHappened    self expectationWithDescription   something happened     testedObject doSomethigAsyncWithCompletion   BOOL succeeded  NSError  error         somethingHappened fulfill        self waitForExpectationsWithTimeout 1 handler NULL

User · Answer

In addition to the semaphore technique covered exhaustively in other answers  we can now use XCTest in Xcode 6 to perform asynchronous tests via XCTestExpectation  This eliminates the need for semaphores when testing asynchronous code  For example   -  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         For the sake of future readers  while the dispatch semaphore technique is a wonderful technique when absolutely needed  I must confess that I see too many new developers  unfamiliar with good asynchronous programming patterns  gravitate too quickly to semaphores as a general mechanism for making asynchronous routines behave synchronously  Worse I ve seen many of them use this semaphore technique from the main queue  and we should never block the main queue in production apps    I know this isn t the case here  when this question was posted  there wasn t a nice tool like XCTestExpectation  also  in these testing suites  we must ensure the test does not finish until the asynchronous call is done   This is one of those rare situations where the semaphore technique for blocking the main thread might be necessary    So with my apologies to the author of this original question  for whom the semaphore technique is sound  I write this warning to all of those new developers who see this semaphore technique and consider applying it in their code as a general approach for dealing with asynchronous methods  Be forewarned that nine times out of ten  the semaphore technique is not the best approach when encounting asynchronous operations  Instead  familiarize yourself with completion block closure patterns  as well as delegate-protocol patterns and notifications  These are often much better ways of dealing with asynchronous tasks  rather than using semaphores to make them behave synchronously  Usually there are good reasons that asynchronous tasks were designed to behave asynchronously  so use the right asynchronous pattern rather than trying to make them behave synchronously

[objective-c] How do I wait for an asynchronously dispatched block to finish?

Examples related to objective-c

Examples related to unit-testing

Examples related to grand-central-dispatch