Since its concurrent queue, tasks may not finish in the order they are added to queue. But with synchronous operation it does although they may be processed by different threads. So, it behaves as this is the serial queue. Remember using GCD you are only adding task to the Queue and performing task from that queue.
dispatch_barrier_sync(queue,void(^block)()) executes all the task blocks added before barrier in queue, then executes the block of barrier task, and then executes the task blocks added after barrier.
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.
Returns a system-defined global concurrent queue with the specified quality-of-service class.
Yes. Using serial queue ensure the serial execution of tasks. The only difference is that dispatch_sync
only return after the block is finished whereas dispatch_async
return after it is added to the queue and may not finished.
for this code
dispatch_async(_serialQueue, ^{ printf("1"); });
printf("2");
dispatch_async(_serialQueue, ^{ printf("3"); });
printf("4");
It may print 2413
or 2143
or 1234
but 1
always before 3
for this code
dispatch_sync(_serialQueue, ^{ printf("1"); });
printf("2");
dispatch_sync(_serialQueue, ^{ printf("3"); });
printf("4");
it always print 1234
Note: For first code, it won't print 1324
. Because printf("3")
is dispatched after printf("2")
is executed. And a task can only be executed after it is dispatched.
The execution time of the tasks doesn't change anything. This code always print 12
dispatch_async(_serialQueue, ^{ sleep(1000);printf("1"); });
dispatch_async(_serialQueue, ^{ printf("2"); });
What may happened is
and you always see 12
The difference between dispatch_sync
and dispatch_async
is simple.
In both of your examples, TASK 1
will always execute before TASK 2
because it was dispatched before it.
In the dispatch_sync
example, however, you won't dispatch TASK 2
until after TASK 1
has been dispatched and executed. This is called "blocking". Your code waits (or "blocks") until the task executes.
In the dispatch_async
example, your code will not wait for execution to complete. Both blocks will dispatch (and be enqueued) to the queue and the rest of your code will continue executing on that thread. Then at some point in the future, (depending on what else has been dispatched to your queue), Task 1
will execute and then Task 2
will execute.
It is all related to main queue. There are 4 permutations.
i) Serial queue, dispatch async : Here the tasks will execute one after the other, but the main thread(effect on UI) will not wait for return
ii) Serial queue, dispatch sync: Here the tasks will execute one after the other, but the main thread(effect on UI) will show lag
iii) Concurrent queue, dispatch async : Here the tasks will execute in parallel and the main thread(effect on UI ) will not wait for return and will be smooth.
iv) Concurrent queue, dispatch sync : Here the tasks will execute in parallel, but the main thread(effect on UI) will show lag
Your choice of concurrent or serial queue depends on if you need an output from a previous task for the next one. If you depend on the previous task, adopt the serial queue else take concurrent queue.
And lastly this is a way of penetrating back to the main thread when we are done with our business :
DispatchQueue.main.async {
// Do something here
}
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With