The following things are what I know & understand:
Global queue is a concurrent queue which can dispatch tasks to multiple threads.
The relationship between the main thread's run loop and the main dispatch queue is merely that they're both run on the main thread and that blocks dispatched to main queue are interleaved on the main thread with events processed on the main runloop.
As the Concurrency Programming Guide says:
The main dispatch queue is a globally available serial queue that executes tasks on the application’s main thread. This queue works with the application’s run loop (if one is present) to interleave the execution of queued tasks with the execution of other event sources attached to the run loop. Because it runs on your application’s main thread, the main queue is often used as a key synchronization point for an application.
When dispatching to background thread, it does not create a NSRunLoop
for those worker threads. Nor do you generally need a run loop for these background threads. We used to have to create our own NSRunLoop
for background threads (e.g. when scheduling NSURLConnection
on background thread), but this pattern is not required very often anymore.
For things historically requiring run loops, there are often better mechanisms if running them on a background thread. For example, rather than NSURLConnection
, you'd now use NSURLSession
. Or, rather than NSTimer
on NSRunLoop
on background thread, you'd create a GCD timer dispatch source.
Regarding who "knows" the thread, the worker thread is identified when dispatched to a queue. The thread is not a property of the queue, but rather assigned to the queue when the queue needs it.
If you want to create a NSRunLoop
for a worker thread (which you generally shouldn't be doing, anyway), you create it and keep track of it yourself. And, when scheduling a thread with a run loop, I would be inclined to create the NSThread
myself and schedule the run loop on that, rather than tying up one of GCD's worker threads.