I'm struggling to fully understand the concurrent and serial queues in GCD. I have some issues and hoping someone can answer me clearly and at the point.
I'm reading that serial queues are created and used in order to execute tasks one after the other. However, what happens if:
I create a serial queue
I use dispatch_async (on the serial queue I just created) three times to dispatch three blocks A,B,C
Will the three blocks be executed:
in order A,B,C because the queue is serial
OR
concurrently (in the same time on parralel threads) because I used ASYNC dispatch
I'm reading that I can use dispatch_sync on concurrent queues in order to execute blocks one after the other. In that case, WHY do serial queues even exist, since I can always use a concurrent queue where I can dispatch SYNCHRONOUSLY as many blocks as I want?
A simple example: you have a block that takes a minute to execute. You add it to a queue from the main thread. Let's look at the four cases.
async - concurrent: the code runs on a background thread. Control returns immediately to the main thread (and UI). The block can't assume that it's the only block running on that queue
async - serial: the code runs on a background thread. Control returns immediately to the main thread. The block can assume that it's the only block running on that queue
sync - concurrent: the code runs on a background thread but the main thread waits for it to finish, blocking any updates to the UI. The block can't assume that it's the only block running on that queue (I could have added another block using async a few seconds previously)
sync - serial: the code runs on a background thread but the main thread waits for it to finish, blocking any updates to the UI. The block can assume that it's the only block running on that queue
Obviously you would used either of the last two for long running processes. You normally see it when you're trying to update the UI (always on the main thread) from something that may be running on another thread.
So you are telling me that: (1)the queue's type (conc or serial) is the ONLY element that decides whether the tasks are executed in order or in paralel;; (2)the dispatch type (sync or async) is only saying whether the execution goes OR doesn't go to the next instruction? I mean, if I dispatch a task SYNC the code will block until that tasks finishes, no matter what queue it's executed on? –
Bogdan AlexandruOct 4 '13 at 11:22
2
@BogdanAlexandru Correct. The queue dictates the execution policy, not how you queue the block. Sync waits for the block to complete, async doesn't. –
JanoOct 4 '13 at 11:25
I'm struggling to fully understand the concurrent and serial queues in GCD. I have some issues and hoping someone can answer me clearly and at the point.
I'm reading that serial queues are created and used in order to execute tasks one after the other. However, what happens if:
I create a serial queue
I use dispatch_async (on the serial queue I just created) three times to dispatch three blocks A,B,C
Will the three blocks be executed:
in order A,B,C because the queue is serial
OR
concurrently (in the same time on parralel threads) because I used ASYNC dispatch
I'm reading that I can use dispatch_sync on concurrent queues in order to execute blocks one after the other. In that case, WHY do serial queues even exist, since I can always use a concurrent queue where I can dispatch SYNCHRONOUSLY as many blocks as I want?
A simple example: you have a block that takes a minute to execute. You add it to a queue from the main thread. Let's look at the four cases.
async - concurrent: the code runs on a background thread. Control returns immediately to the main thread (and UI). The block can't assume that it's the only block running on that queue
async - serial: the code runs on a background thread. Control returns immediately to the main thread. The block can assume that it's the only block running on that queue
sync - concurrent: the code runs on a background thread but the main thread waits for it to finish, blocking any updates to the UI. The block can't assume that it's the only block running on that queue (I could have added another block using async a few seconds previously)
sync - serial: the code runs on a background thread but the main thread waits for it to finish, blocking any updates to the UI. The block can assume that it's the only block running on that queue
Obviously you would used either of the last two for long running processes. You normally see it when you're trying to update the UI (always on the main thread) from something that may be running on another thread.
So you are telling me that: (1)the queue's type (conc or serial) is the ONLY element that decides whether the tasks are executed in order or in paralel;; (2)the dispatch type (sync or async) is only saying whether the execution goes OR doesn't go to the next instruction? I mean, if I dispatch a task SYNC the code will block until that tasks finishes, no matter what queue it's executed on? –
Bogdan AlexandruOct 4 '13 at 11:22
2
@BogdanAlexandru Correct. The queue dictates the execution policy, not how you queue the block. Sync waits for the block to complete, async doesn't. –
JanoOct 4 '13 at 11:25
转自出处： http://stackoverflow.com/questions/19179358/concurrent-vs-serial-queues-in-gcd8down votefavorite6I'm struggling to fully understand the concurrent
303
到【灌水乐园】发言
