0

im studying multithreading and what i want is some clarification on subject matter.

As far as i know, SERIAL queue execute tasks serially, are always executing one task at a time.

Now, SYNCHRONOUS function is a function, that returns only after all tasks complete.

Now, i'm a bit confused. What difference between those two?

if i understand correct, both of them will block current thread (if they are not "covered" in global concurrent queue), and both of them execute tasks exactly in FIFO order.

So, what exactly a difference between them? Yes, i understand that serial is a property of a queue, and sync is a function (or operation). But their functionality is like to be similiar.

Evgeniy Kleban
  • 6,794
  • 13
  • 54
  • 107
  • I can add tasks to a serial queue without necessarily blocking my current thread. Those tasks execute in order but without any implicit effect on the thread that submits the work. – Phillip Mills Jul 15 '15 at 15:50
  • @PhillipMills you mean, if we create a queue, that separate from main thread, and that queue would be serial and code will run separately from main thread? – Evgeniy Kleban Jul 15 '15 at 15:51
  • 1
    Yes. When you create a queue for background use, you can make it serial. Then the code that uses it decides whether to wait for task completion or not. – Phillip Mills Jul 15 '15 at 16:10
  • @PhillipMills thank you for clarify :) – Evgeniy Kleban Jul 15 '15 at 16:10

1 Answers1

1

You are comparing a queue with a function, so it is difficult to define "difference". Using a serial queue does guarantee sequential behaviour of its operations. Typically, you use a synchronous dispatch if your program has to wait for all queued operations to complete before your program completes. If every dispatch on a given queue is synchronous, then indeed there is no difference between using a queue or calling the operations.

However, here is a very useful case that shows the difference. Suppose operation A is lengthy and you do not want to block. Suppose operation B returns something computed by operation A, but it is called some arbitrary time later (like in response to a user action). You dispatch_async A onto the queue. Your program is not blocked. Sometime later, you need the result. You dispatch_sync operation B on the same serial queue.

Now if A is already complete, the queue is empty when you add B and B executes immediately. But (and here is the good part) if A is still executing (asynchronously), B is not dispatched until A is done, so your program is blocked until the result it needs is ready.

For more explanation of this, see here.

The dangers of deadlock nicely handled for you by gcd.

Community
  • 1
  • 1
  • thank you, but in your example why should we use dyspatch_sync, instead of get to main queue and proceed computation in it (when we got result from an operation A)? – Evgeniy Kleban Jul 15 '15 at 16:18
  • Sorry, but I don't understand your question in this comment. In my answer, I am assuming the use of gcd (Grand Central Dispatch) for queue management and synchronous vs. asynchronous behaviour. –  Jul 15 '15 at 16:37