GCD does not use any kind of "event loop". This is a new kernel feature in recent releases of Mac OS X and iOS; in fact, I don’t have any other similar technology that I know of.
The goal is to complete the execution of all the code that you pass as fast as the hardware allows. Please note that it targets the fastest end time, not the fastest start time. Subtle difference, but important with real impact on the world, how it works.
If you have only one idle processor core, theoretically only one of them will run at a time. Since multitasking inside one core is slower than performing two tasks in sequence. But actually it is not. If the CPU core becomes inactive or not very busy for some time (for example, reading a hard disk or waiting for a response from some other program (Xcode draws the output of NSLog)), then it will most likely go on to execute for a second GCD, because the one he's doing now is stuck.
And, of course, most of the time you will have more than one idle processor core.
He also will not necessarily do things in the order in which you give it. The GCD / core controls these details.
In your specific example, the Xcode debugger is probably able to handle only one NSLog() event at a time (at least it should do the drawing one at a time). You have two queues and they can start execution at the same time. If you send two NSLog() statements at once, one of them will wait for the other to finish first. Since you do nothing but print material in Xcode, these two GCD queues will be the first to race to send log data to Xcode. The first has a small initial start, but it is very small and often not enough for it to first open a connection to Xcode.
It all depends on what actual hardware resources are available on the hardware for that particular nanosecond in time. You cannot predict it, and you need to properly structure your lines in order to take some control.