Question

How to control and balance the number of threads my app is executing, how to limit their number to avoid app’s blocking because thread limit is reached?

Here on SO I saw the following possible answer: “Main concurrent queue (dispatch_get_global_queue) manages the number of threads automatically” which I don’t like for the following reason:

Consider the following pattern (in my real app there are both more simple and more complex examples):

dispatch_queue_t defaultBackgroundQueue() {
    return dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
}

dispatch_queue_t databaseQueue() {
    dispatch_queue_create("Database private queue", 0);
}

dispatch_async(defaultBackgroundQueue(), ^{
    [AFNetworkingAsynchronousRequestWithCompletionHandler:^(data){
        dispatch_async(databaseQueue(), ^{
            // data is about 100-200 elements to parse
            for (el in data) {

            }

            maybe more AFNetworking requests and/or processing in other queues or

            dispatch_async(dispatch_get_main_queue(), ^{
                // At last! We can do something on UI.
            });
        });
    }];
});

This design very often leads to the situation when:

1. The app is locked because of threads limit is reached (something like > 64)
2. the slower and thus narrow queues can be overwhelmed with a large number of pending jobs.
3. the second one also can produce a cancellation problem – if we have 100 jobs already waiting for execution in a serial queue we can’t cancel them at once.

The obvious and dumb solution would be to replace sensitive dispatch_async methods with dispatch_sync, but it is definitely the one I don’t like.

What is recommended approach for this kind of situations?

I hope an answer more smart than just “Use NSOperationQueue – it can limit the number of concurrent operations” does exist (similar topic: Number of threads with NSOperationQueueDefaultMaxConcurrentOperationCount).

UPDATE 1: The only decent pattern is see: is to replace all dispatch_async’s of blocks to concurrent queues with running these blocks wrapped in NSOperations in NSOperationQueue-based concurrent queues with max operations limit set (in my case maybe also set a max operations limit on the NSOperationQueue-based queue that AFNetworking run all its operations in).

Answer 1

You are starting too many network requests. AFAIK it’s not documented anywhere, but you can run up to 6 simultaneous network connections (which is a sensible number considering RFC 2616 8.1.4, paragraph 6). After that you get locking, and GCD compensates creating more threads, which by the way, have a stack space of 512KB each with pages allocated on demand. So yes, use NSOperation for this. I use it to queue network requests, increase the priority when the same object is requested again, pause and serialize to disk if the user leaves. I also monitor the speed of the network requests in bytes/time and change the number of concurrent operations.