There's a huge difference: the global queue is concurrent while your video queue is serial.
If you submit two blocks directly to the global queue, the system is allowed to run them concurrently.
If you submit two blocks to your video queue, the system must run them sequentially (not concurrently). The first block you submitted must return before the queue is allowed to call the second block. This means you can use your video queue as a serialization/locking mechanism to access state in a thread-safe way.
Other differences that I'm aware of:
In Xcode's debug navigator, the queues are labeled differently.
You can set the autorelease frequency of the video queue that you created.
If you set a quality-of-service class on the video queue when you create it, that QoS will override the QoS of the target queue.
You can suspend and resume dispatching on your video queue. I'm not sure if suspend
and resume
work on the global queue, but if they do, I'm sure suspending a global queue is a bad idea. You don't know what important tasks the system might be queuing on the global queues.
You can setSpecific
values on your video queue, and then access them using getSpecific
in blocks queued to the video queue. But getSpecific
will not return those values in blocks queued directly to the global queue. This is most often used to detect when API calls are made on a particular queue, for thread-safety reasons.