How current queue, dispatch queue and target queue communicates with each other in GCD?

Question

I was following blogs, online articles, videos for GCD, and I come across a term target queue(on some of the blogs). I thought I understood GCD, but then this target queue terminology really confused me.

What I understood is:

For example:

viewdidload(){
       DispatchQueue.main.async{
          print("hello world")
       }
}

• current queue: main queue, as viewdidload called from main thread.
• dispatch queue: main queue because "DispatchQueue.main"
• target queue: well I am not sure about it, it can be concurrent queue, but then how current queue, dispatch queue and target queue communicates with each other in GCD?

Answer 1

A target queue is a somewhat advanced topic that isn’t used very often. Unless you have very specific needs (see below), you can safely ignore this feature.

When you create a custom queue, you can define it to have a target, a queue that your custom queue will use behind the scenes. So if you create a queue, A, with a target queue, T, then anything dispatched to A will actually run on T. So, you might ask when one might be inclined to use this pattern:

1. Perhaps you have several queues that you want to share some behavior. For example, you might have queues A, B, and C that all are using serial queue T as their target. Then, not only will A, B, and C be serial, individually, but across A, B, and C, too. E.g. dispatch something to A and another thing to queue B, the task on B will wait for the task on A to finish (because of the serial nature of T, their shared target queue).

   Or imagine that you have three concurrent queues, A, B, and C, but you occasionally want to do a barrier across all three, some critical task that cannot run concurrently with respect to anything running on those three queues. If, when you creating A, B, and C, you specified concurrent queue T to be the target queue for all of them, if you add a barrier task to T, then A, B, and C will all honor that barrier.

2. You might use target queues if you profile your code and you discover that you have a very high number of “context switches” taking place where your GCD code is resulting in constant jumping between different threads. For common GCD applications (e.g. run this computationally expensive code on some background queue, and then dispatch the update back to the main queue), this target queue concept offers no practical benefit. But if you’re doing thousands/millions of dispatches between GCD queues, it might be relevant. But profile your code before you bother, to detect how many context switches are happening and see if this will offer any practical benefit in your scenario.

   For examples of where you might use target queues for these performance related issues, see WWDC 2017 video Modernizing Grand Central Dispatch Usage: Introducing Unified Queue Identity. In the above link, I’ve tried to drop you off in the relevant portion of the video, but watching the whole video might offer greater context.

Bottom line, there are cases where you might need to specify a target queue, but it’s pretty uncommon in practice.