Synchronization callbacks - block vs GCD queue

Question

I am new to asynchronous callbacks and have been given differing advice. I need to perform asynchronous callbacks and after many hours of research I still do not know if I should use blocks or GCD and queues. Any pointers would be welcome.

OK. So what I was really asking is:

"in order to use an 'asynchronous' callbacks, do I need to use GCD and queues?"

What I am gathering from the answers is that the answer is YES. Definitely GCD and queues inside of blocks.

My confusion stemmed from the fact that I had been given the direction that all I needed was a block, like the code below:

[UIView animateWithDuration:.4f
                 animations:^{
                     flashView.alpha = 0.f;
                 }
                 completion:^(BOOL finished){
                     [flashView removeFromSuperview];
                 }
 ];

But what I am seeing in the answers here is that the above block in not sufficient for making 'asynchronous' callbacks. Instead I DO in-fact need to use GCD and queues inside a block, like the code below:

- (void)invokeAsync:(id (^)(void))asyncBlock resultBlock:(void (^)(id))resultBlock errorBlock:(void (^)(id))errorBlock {
    dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
    dispatch_async(queue, ^{
        NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
        id result = nil;
        id error = nil;
        @try {
            result = asyncBlock();
        } @catch (NSException *exception) {
            NSLog(@"caught exception: %@", exception);
            error = exception;
        }
        // tell the main thread
        dispatch_async(dispatch_get_main_queue(), ^{
            NSAutoreleasePool *secondaryPool = [[NSAutoreleasePool alloc] init];
            if (error != nil) {
                errorBlock(error);
            } else {
                resultBlock(result);
            }
            [secondaryPool release];
        });
        [pool release];
    });
}

Answer 1

An asynchronous callback is one where your current thread keeps executing statements, and you detach the execution of code in a different thread to be ran later.

There are several technologies to accomplish this. On this example I'm calling the method cacheImage:, with parameter image (just an example) in 4 different asynchronous ways.

// 1. NSThread
[NSThread detachNewThreadSelector:@selector(cacheImage:) toTarget:self withObject:image];

// 2. performSelector...
[self performSelectorInBackground:@selector(cacheImage:) withObject:image];

// 3. NSOperationQueue
NSInvocationOperation *invOperation = [[NSInvocationOperation alloc] initWithTarget:self selector:@selector(cacheImage:) object:image];
NSOperationQueue *opQueue = [[NSOperationQueue alloc] init];
[opQueue addOperation:invOperation];

// 4. GCD
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
    [self cacheImage:image];
});

By far the more simple way is to use GCD because it already has a thread ready for you to use, instead having to create it yourself with the other options.

However, because blocks are implemented as objects, you could indeed use blocks without GCD, for example:

// block definition
typedef void (^hello_t)();

// method that uses a block as parameter
-(void) runBlock:(hello_t)hello {
    hello();
}

// asynchronous execution of a block
[NSThread detachNewThreadSelector:@selector(runBlock) toTarget:self withObject:^(){
    NSLog(@"hi");
}];

PS: you don't need to use NSAutoreleasePool manually unless you create many many objects and you want to free memory immediately. Also, @try @catch are rarely used in Objective-C

Answer 2

Not any point of confusion here. GCD also has a block execution. GCD API, which supports the asynchronous execution of operations at the Unix level of the system.

Block objects are a C-level syntactic and runtime feature. They are similar to standard C functions, but in addition to executable code they may also contain variable bindings to automatic (stack) or managed (heap) memory. A block can therefore maintain a set of state (data) that it can use to impact behavior when executed.

Apple designed blocks with the explicit goal of making it easier to write programs for the Grand Central Dispatch threading architecture, although it is independent of that architecture and can be used in much the same way as closures in other languages. Apple has implemented blocks both in their own branch of the GNU Compiler Collection and in the Clang LLVM compiler front end. Language runtime library support for blocks is also available as part of the LLVM project.

Therefore you can use any one of them given you same functionality.