How to wrap an asynchronous class to make it synchronous? Use NSRunLoop?

Question

I'm currently working on an iPhone app and I have a library from a third-party that has asynchronous behavior but that I'd like to wrap with my own class and make it appear synchronous.

The central class in this library, let's call it the Connection class, has several functions that have their ultimate result resolved when methods on an instance of a delegate class are called. What I'm trying to do is wrap this class and delegate so that it appears to be synchronous instead of asynchronous. If I were doing this in Java I would use FutureTask or a CountdownLatch or just join(). But I'm not sure the best way to do this in Objective C.

I started by creating a NSThread extenstion, NFCThread, which conforms to the above mentioned delegate protocol. The idea is that I would init and NFCThread, pass the NFCThread instance to Connection's setDelegate method, start the thread and then call an asynchronous method on Connection. My expectation is that one of the three delegate methods on the NFCThread instance would be called ultimately causing the thread to exit.

To simulate a join I did the following. I added a NSConditionalLock to NFCThread:

joinLock = [[NSConditionLock alloc] initWithCondition:NO];

The code around the call to Connection looks something like this:

NFCThread *t = [[NFCThread alloc] init];
[connection setDelegate:t];
[t start];

[connection openSession];
// Process errors, etc...

[t.joinLock lockWhenCondition:YES];
[t.joinLock unlock];
[t release];
[connection setDelegate:nil];

The protocol for the delegate has three methods. In NFCThread I implemented each method something like this:

- (void)didReceiveMessage:(CommandType)cmdType 
                     data:(NSString *)responseData 
               length:(NSInteger)length {
    NSLog(@"didReceiveMessage");
    // Do something with data and cmdType...
    [joinLock lock];
    [joinLock unlockWithCondition:YES];
    callBackInvoked = YES;
}

I overloaded NFCThread's main method so that it just loops continually. Something like this:

while (!callBackInvoked) { ; }

I found that this isn't really a good idea since it cause cpu usage to go through the roof. So instead I tried using a run loop from some examples I found on this site:

NSRunLoop *runLoop = [NSRunLoop currentRunLoop];
[runLoop addPort:[NSMachPort port] forMode:NSDefaultRunLoopMode];

while (!callBackInvoked) {
    [runLoop runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
}

In both of my implementations the main thread is always blocked and it appears that none of the delegate methods are ever called. However, I know that the library is functioning properly and that calls to the delegate methods are normally called.

I feel like I'm missing something obvious here. Any help much appreciated.

Rich

Answer 1

Ok, so there are a few different issues here, I'm trying to think where to start.

But just so we understand what you're trying to accomplish, when you say you want the call to "appear" synchronous, do you mean you want the call to block? Are you making this call from the main thread? If so, then it seems you are blocking the main thread by design.

Keep in mind the third party library is probably scheduling events on the main run loop. You can create your own run loop and run it in another thread, but have you told the other library to use that run loop for its events? (For example, it could be making async network requests that are scheduled on the main run loop which you have blocked)

I would rethink what you're doing a bit, but first we would need to know if your intention is to block the thread from which you are making this call. Also, do you need to support iPhoneOS 3.x?

Answer 2

You want a semaphore, which will allow your primary codepath to block until your asynchronous callback signals the semaphore and allows it to continue.

Semaphores are available in iOS 4 through Grand Central Dispatch.

It appears that the behavior of semaphores can be implemented in iOS 3 with NSCondition.

Answer 3

I just implemented something similar. The context was: - wrap several calls to ZipArchive in a background thread - for each call to unzip, display a different progress meter (infinitely spinning wheel with the name of the file being expanded) - perform a cleanup task when all the archives have been expanded

Turns out NSConditionLock makes it straightforward, and the code works as follows:

NSConditionLock* lock = alloc/init
for(int idx = 0; idx < [list count]; idx++) {
  NSString* fileName = ["getIdx's element in list"]
  [cond lockWhenCondition:idx]; //

  ... prepare things before forking

  [cond unlockWithCondition:-1];
  [Notification forkBlock:^(void){
    [cond lockWhenCondition:-1];

    NSAutoreleasePool *pool = [alloc/init];
    [ZipArchive unzipFile:fileName];
    [pool release];
    [cond unlockWithCondition:idx+1];
  }];
}

[cond lockWhenCondition:[list count];
// all the tasks are now completed

Each of the blocks are scheduled in a background thread. The Notification class takes care of animating the UIView with the spinning wheel and wrapping the block in another thread. Lock/unlock must be called from the same thread, so the condition is what enables the ping-pong between from and background threads (-1 for the background, 1,2,3..n for the foreground).

Answer 4

What you want to do is to use NSCondition to wait on the current thread, and signal on the second thread to let the first one continue.

- (void) firstThread
{
    workIsDone = NO;
    //Start second thread here
    [condition lock];
    while (!workIsDone) {
        [condition wait];
    }
    [condition unlock];

    // Keep going
}

- (void) secondThread
{
    [condition lock];

    //Do some work.
    workIsDone = YES;
    [condition signal];
    [condition unlock];
}