如何使异步呼叫同步

Question

I am overriding a callback method in order to process a response of an HTTP request.

-(NSObject<HTTPResponse> *)httpResponseForMethod:(NSString *)method URI:(NSString *)path{
    NSObject <HTTPResponse> *response;
    // Here I should load the data
}

However, in my request I have to load some data which only works asynchronously:

- (void)assetForURL:(NSURL *)assetURL resultBlock:(ALAssetsLibraryAssetForURLResultBlock)resultBlock failureBlock:(ALAssetsLibraryAccessFailureBlock)failureBlock;

Since I am in a synchonous method, I can't "leave" the method before I have the data. Also I can't pre-load the required data since I don't know which asset is required until I am in the request.

This seems to be quite a tricky design problem for me and I can't see a solution how to solve this without some major hacks.

Answer 1

EDIT: stevex is absolutely right that your first priority should be to find a way just to make the whole thing asynchronous. Failing that, the answer below should achieve what you want while entrusting the synchronisation steps to the OS for optimal power usage.

Probably you want to use an NSConditionLock to lock the thing that calls assetForUrl:... immediately after the call, then have your callbacks unlock it.

A condition lock is a lock with a condition. So you say 'I want the lock when its condition is X' and your thread blocks until it is in that condition. You then have the lock until you unlock it, and you get to specify what condition it will be in immediately upon becoming unlocked.

The conditions are specified with NSIntegers;

So there's an aspect of communications built into the lock.

So, for example:

NSConditionLock *conditionLock; // somewhere; an instance variable

#define kYourClassInitialCondition 0
#define kYourClassWaitingCondition 1
// etc

...

[conditionLock lockWhenCondition:kYourClassInitialCondition];

[whomever assetForUrl:whatever
          resultBlock:^(args here)
                      {
                         ... do relevant immediate work here ...

                         [conditionLock lockWhenCondition:kYourClassWaitingCondition];
                         [conditionLock unlockWithCondition:kYourClassFinishedCondition];
                      }
          failureBlock:^(args here)
                      {
                         ... as above, same semantics when done ...
                      }
 ];


[conditionLock unlockWithCondition:kYourClassWaitingCondition];

[conditionLock lockWhenCondition:kYourClassFinishedCondition];
[conditionLock unlockWithCondition:kYourClassInitialCondition];

So, logic on the calling thread is:

• acquire the lock in the initial condition
• issue the URL fetch request
• release the lock in the waiting condition
• acquire the lock in the finished condition
• release the lock in the initial condition

And logic on the result blocks is:

• acquire the lock in the waiting condition
• release the lock in the finished condition

The result blocks will block until the calling thread has put the condition lock into the waiting condition. So there's no problem with sequencing if the callbacks are immediate.

After establishing the waiting condition, the calling thread will block until the condition lock is released in the finished condition. So it should then wait for a result block to complete if one hasn't completed already.

This, of course, assumes that your result blocks are dispatched through GCD by the callee, or if called inline are called from a separate thread. The former is probably a safe assumption.