Concurrent vs serial queues in GCD

转自出处： 

http://stackoverflow.com/questions/19179358/concurrent-vs-serial-queues-in-gcd

8down votefavorite

6

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.

1. 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

2. 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?

   Thanks for any good explanation!

ios multithreading concurrency grand-central-dispatch

share|improve this question

edited Oct 4 '13 at 11:22

Jano
39.9k1394129

asked Oct 4 '13 at 10:47

Bogdan Alexandru
939719

 

add a comment

1 Answer

activeoldestvotes

up vote12down voteaccepted

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.

share|improve this answer

answered Oct 4 '13 at 11:12

Stephen Darlington
35k464111

 

 

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 Alexandru Oct 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. –  Jano Oct 4 '13 at 11:25

 

Thanks Stephen and @Jano, now it all makes sense! –  Bogdan Alexandru Oct 4 '13 at 11:37

 

Please also see my next question here: stackoverflow.com/questions/19180661/… –  Bogdan AlexandruOct 4 '13 at 11:59

 

Simple and brilliant –  onmyway133 May 29 at 16:51

8down votefavorite

6

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.

1. 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

2. 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?

   Thanks for any good explanation!

ios multithreading concurrency grand-central-dispatch

share|improve this question

edited Oct 4 '13 at 11:22

Jano
39.9k1394129

asked Oct 4 '13 at 10:47

Bogdan Alexandru
939719

 

add a comment

1 Answer

activeoldestvotes

up vote12down voteaccepted

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.

share|improve this answer

answered Oct 4 '13 at 11:12

Stephen Darlington
35k464111

 

   

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 Alexandru Oct 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. –  Jano Oct 4 '13 at 11:25

   

Thanks Stephen and @Jano, now it all makes sense! –  Bogdan Alexandru Oct 4 '13 at 11:37

   

Please also see my next question here: stackoverflow.com/questions/19180661/… –  Bogdan AlexandruOct 4 '13 at 11:59

   

Simple and brilliant –  onmyway133 May 29 at 16:51