Good morning everyone! And welcome to Introducing Blocks in Grand Central Dispatch on iPhone. Looks like we have a pretty full room today. If you have friends who weren't able to make it inside we will be repeating this session later in the week. More details on that to come.

My name is Kevin van Vechten. I'm the engineering manager of the Grand Central Dispatch team at Apple. And last year we were very excited to release Grand Central Dispatch and Blocks in Mac OS X Snow Leopard. Blocks is a language feature that allows you to organize your code into independent snippets of code for easy reuse and Grand Central Dispatch is a runtime API that lets you execute those snippets of code asynchronously and in an event driven fashion.

It is a very low level technology. It's part of libSystem. It's available for all applications to use without needing to link against any additional libraries and frameworks. And this year, we're very excited to announce its availability in iOS 4 for use by your UIKit applications. So with all of last year's emphasis on the multicore benefits of Grand Central Dispatch you may be wondering whether there are any real world benefits to an iPhone or an iPad that only has a single core. And the answer is yes.

Fundamentally, Grand Central Dispatch is a very efficient runtime for intrathread communication and asynchronous execution and these benefits scale up to many cores as we see on the Mac or scale down to a single core as we see on the iPhone and iPad. And by running work asynchronously it allows you to free up your main threads event loop to keep your application responsive to the user especially for touch events. So please join me in welcoming Bill Bumgarner to the stage to talk more about Blocks.

Thanks Kevin. So if you saw the talk earlier today about effective use of Objective-C. I'm going to be repeating some of the concepts from that and maybe a little bit different and then we're going to repeat it again a little later in the week. And part of the reason why we're doing this repetition is because Blocks are pervasive. They're our foundation. They're throughout everything and by understanding this technology effectively you will be able to take advantage of it and your code will be simpler, faster, more efficient, more stable, which let's you ship better apps.

So with that let's talk about Blocks. Now, if you've come to this platform from other languages like the scheme list Ruby, Smalltalk, then you're probably familiar with lambdas, closures, Blocks even they're called, or anonymous functions. JavaScript has anonymous functions with querying and in Snow Leopard like Kevin said we added this concept to see, we call it Blocks. We use a very simple syntax but that simple syntax belies an underlying power.

Now, on our platform are the foundation languages C. Out of C we have Objective-C. We have C++. And of course we smashed the two together in an unholy marriage called objective C++.

So where are Blocks available? Blocks are available fully and completely in C and Objective-C.

However, the C++ and objective C++ report is not quite complete. Though I am exceedingly happy to be the first on stage I think to tell you that in LLVM 2.0 top of tree the Block support passes all 912 unit tests in C++.

And if you want to play with that you can grab LLVM 2.0 from the llvm.org site.

So, basic Blocks. What is the most common patterns you're going to see with Blocks and how are you most commonly going to use them? Well, quite literally you will be using the caret everywhere. You see the caret, this operator? That introduces a Block. Why caret? It's the only unary operator we knew of that could not be operator overloaded in C++, so.

Makes things a little simpler, that and we couldn't use the snow man because Unicode is not allowed.

So when you're writing code and you want to take advantage of Blocks. There's a lot of APIs that take Blocks as arguments. These are two of them, one is Objective-C. One is from Grand Central Dispatch that you'll hear more about shortly and quite literally, you throw a Block Literal in your code. You pass it as an argument.

It can do some work. It can return values and it's, you know, simple elegant in line. Now, two things of note: one, by a standard we generally only pass one Block as an argument to anything and it is always the last argument. That was two. And by doing this it just simply makes the code more readable. So if you write your own APIs to take blocks try to stick with that. There's occasion where it's violated but hopefully for good reason.

So when we look at the Block Literal syntax, the Block Literals, what does the syntax look like? Here is an arbitrary Block. Returns a BOOL. Takes an argument called of type ID. It does something simple and this is what the syntax looks like. Now we also wanted Blocks to be exceedingly convenient to use.

And so if you don't return a specific type you don't need to declare that type or the compiler can actually automatically infer the type, there's no need for the return type in. Similarly, if you don't take any arguments, you get a void argument list and a void return type of an inferred return type. You're going to just drop all of that and have a very simple Block Literal. Most of the APIs that your going to see shortly take this form. Now, Blocks are more than just code. Blocks can be treated as data.

That's kind of how dispatch and other things work. They allow you to capture code and some state as a chunk of data that get managed and cued, and executed and handled automatically behind the scenes. So how does this work? Well, in C we had function pointers, we've always had function pointers. That was kind of, how you could pass around callbacks and stuff. But there was no way to attach data to it. So Block Pointers look very, very similar. It's simply the caret instead of the pointer.

Now, of course this can get ugly very quick like most C types. When you start returning pointers to stuff that return pointers to other stuff that has functions and blocks and stuff, it gets ugly. To simplify that, of course you can use typedefs. So in this case we've declared a typedef that we can capture the type of that Block argument that we're passing to that other block. And let's look at how this works as a whole.

So, we'll define it simple type a Worker Block. It takes in integer as an argument, has no return type. And we can then define a simple function, a repeat function, that will call that Block some number of times and pass the iteration count to the Block as the sole argument, and then we can use it.

So, we declare a variable D, give it a value. We declare this Worker Block which uses that value, and that's interesting because that means the Block is actually capturing the value and then it can be used later. And then we're going to call the repeat function and as you would expect this is the output.

Now, in iOS 4, what I've shown you now is basically the foundations for creating and using your own APIs with Blocks. However, in iOS 4, I haven't gotten used to that yet, there are actually over 100 APIs that use Blocks. Like I said, Blocks are pervasive. You are going to use Blocks if you use the audio kit, if you use core motion, core telephony, the game kit you're going to be using Blocks.

You're going to be declaring Blocks passing to the system. And more than just at the individual framework layers, you're also going to be using Blocks to implement features like multitasking across the foundation kit. You're going to be using it in Grand Central Dispatch very heavily, as you'll see shortly.

So in particular there are four common patterns of usage you will see with Blocks and you are encouraged to embrace these in your own code as well. You have synchronous execution. In this case we are, say, filtering a set or we're enumerating a dictionary exceedingly efficiently. And in this case, you're taking a Block, you're calling some method and it will return, you know, synchronous. There is no concurrency. There is no multitasking here. It's an immediate kind of thing.

It's also-- Blocks are also exceptionally useful in the callback role. So normally with a callback you have some Function Pointer, in a lot of cases. You throw it over somewhere. And then when you get the callback maybe there's a Void Pointer that's your context. You got to do the type cast to some other type and that's really unsafe because it's basically telling the compiler that you know what your doing and often we don't and then your code crashes. With Blocks because you can capture state you don't have to have that context. It makes the API simpler and it makes them more robust. It makes them type safe. So these are actually both examples of APIs you'll find in iOS 4.

Another role you will see is asynchronous execution and you're going to get into this is in depth in a moment. In particular NSOperationQueue and Grand Central Dispatch can both take Blocks that will then be executed later, or on another thread, or whenever. And finally, there is a very interesting role for Blocks, that's really a role provided by Grand Central Dispatch and that's that by having this queued invocations of Blocks you can have lockless exclusion for resources.

In this case, if we say we have a queue and that queue is associated entirely with an image or some data source then every time we dispatch something onto to that queue and that's executed serially, we know that nothing else can touch that resource and the Blocks allow us to capture the work related to that very easily.

So with this pervasive nature of Blocks you need to know some of the details of the implementation, and this is where we're going to get kind of technical. First, Blocks are in fact Objective-C objects, always. They can be messaged as objects. They have very, very few methods. Block objects start out on the stack. Why? Because the stack's really, really fast, making allocation in the heap is relatively expensive.

So for synchronous execution that's fine because your frame where you'd clear the stack or where you'd clear the Block isn't going to go away before the execution is done. However, of course, for asynchronous you need to be able to copy the Block onto the heap. So that stack frame can be destroyed and the Block's not going to explode. And this is where we see two of the methods that Blocks respond to. They respond to the copy method and the release method. There is also an analogous Block_copy and Block_release function that you can use.

So when a Block-- when the code execution passes over a Block declaration, effectively what happens is the Block snapshots or captures a constant copy of any data it references from the surrounding scope. So that also means though that objects, references to objects can be captured in this way and Blocks will actually automatically retain those objects and then will release them when the Block is destroyed. So for example, if you refer to an instance variable, then a reference to self will be captured. Self will be retained and your object will survive for the lifespan of that Block even if the calling scope is destroyed.

Now, of course, const copies are useful most of the time, but sometimes you want to get stuff out. You want the Block to be able to update some of that stuff in that local scope. Or maybe you want three blocks to all be able to kind of share state or have some kind of state map between them. For that, there is a new storage keyword in the C language on our platform called __block.

What that says is that that variable is now going to be mutable from within the Block from within that scope it was declared, from within any other Block that uses it. The issue though is that __block references to objects are not retained. The memory management, you have to do the memory management manually.

The reason why that is, is because there are some very subtle conditions under which it's absolutely impossible to do it automatically. Let's look at this lifetime thing in detail. This is just critical. So we have a simple piece of code down at the bottom there's some function that declares a Block, block1. Block1 updates a shared variable with the captured variable, with the const copy captured. Our program pointer is that big orange ugly arrow pointing right at that code and now we're going to go ahead and we're going to go to the next line of code.

So we passed over the declaration of the block. At this point in time, the Block object has captured the data. The block object is now on the Stack. It has a copy of that captured variable. And notice that the shared variable, nothing happened to it. Because it doesn't need to move yet, it's still on the Stack.

It's fine. So let's go ahead and copy that block and we're going to make a second Block reference block2. At that point in time, block1 is still on the stack. Block2 is now a heap-based allocation and because that shared variable is now referenced by something that might outlast the scope of declaration, it has to be moved to the heap too. And even though it's been moved to the heap block1 still going to work, block2 is going to work.

It's all fine. And let's just see what happens when we actually make a second copy of the Block. In this case, we've copied block1 the second time. We actually have two heap allocations now. I just get a little warning sign because this can be a problem if you're going to say schedule a thousand copies of the Block.

Then you're going to end up with a thousand heap allocations or if that block is capturing a big array that's going to be bad. So how do you avoid that? Well, once the block is copied to the heap there is no reason for the heap to keep accumulating copies. That's a bug.

That line in code it's pointing at right now, that should be block2 copy. Sorry, I don't know how that happened. Anyway, so imagine that was block2 copy. I love it-- live debugging. In keynote even. So, now we have block2 and block3 referring to the same Block on the heap.

There's only one copy of the captured variable. Shared is still on the heap because well, it had two on the first copy, so that's how you can avoid copies. Now, one of the details of the APIs in the system, anytime an API is going to take a Block and potentially execute it, somewhere other than the local thread, somewhere other than where the scope the block was created in may exist or not.

The system APIs will copy the Block. This is generally handled automatically for you. There's one case though you kind of got to keep your, you know, in your head. Because if your going to say enqueue a thousand copies of one Block, make a copy first and then release after.

Anyway, so what happens when the Blocks end? Well, if block2 and block3 finish first and we're assuming garbage collection here. Blocks are fully compatible garbage collection on the desktop. If I had a room on the slide, I would have put Block_release after the execution of the Blocks. Then, the heap stuff gets destroyed. The allocation is gone. The shared variable doesn't move back to the stack because that would be a waste of CPU cycles and life goes on.

Now, if the function and block1 were to finish, if that scope of the function that stack frame for the function gets destroyed, then dip stacks cleared, stacks pop, stuff lives on, on the heap and eventually when execution ends, then of course everything is cleaned up and everything goes away.

So that's Blocks in detail and this will be reiterated again on Friday and in even more depth if you're interested in the advanced Objective-C and Garbage Collection Techniques session. With that, I'd like to pass over to Shiva to dive into detail on Grand Central Dispatch.

Thanks Will. So in the remaining part of this session we're going to show how to use GCD or Grand Central Dispatch to make your apps responsive and without you actually having to do a lot of work. And why do you want to make your apps responsive? Well, you want happy customers and we are all here to make your customers happy.

So before we start let me ask you. How many of you wake up in the morning and say, you know, "My day is not complete today until I write some really hard multi coded thread." Exactly, because threading is a hard problem. Because the way you think about your apps, in a task oriented fashion most probably, is not how easily you can map that thinking into the implementation. Threading is more granular and it's not the way you kind of like think about the implementation as you are thinking about the logistics of your application.

So hopefully at the end of this session you would, all of you would be actually writing multithreaded code and it will be fun. It-- you will be using GCD to do threading without actually thinking about threads and that's a very powerful paradigm to write your code in. And one of the ways we do this is there is no explicit thread management. We do not expose threads to you.

You do not think in terms of thread and therefore you can easily, more easily map your application logic into your code. As Kevin mentioned before, we introduced GCD in Snow Leopard and probably you have gone to other talks and seen people talk about GCD before. So, most of our frameworks are using GCD which means any ad hoc threading implementation that you might do on your own, GCD will probably perform better than that.

And we saw how Blocks are this way to encapsulate your data in the work associated with that data. So with GCD using Blocks, it provides a really powerful expressive way for you to write your code. So, since this is the age of writing Twitter apps, we decided that we will give our shot to writing a similar app.

To give a brief overview, you would see a stream off messages-- a stream of tweets coming along. We want to display those tweets and at the same time, we are going to show the images, the profile images of the people who posted it. Let's move to the demo.

So, we have two demos here. One that probably uses the naive approach of doing most of this work on the main thread, and one of the reasons, one of the things that we have seen people do is you might think that you are doing a nominal amount of work on the main thread, and that's because you're testing on your Wi-Fi network, there is no latency so you figure, "Oh, I will get the synchronous connection. Get the result back and display the output."

But when that application goes in the hand of your customers and they are on a 3G network and on the edge connection, you know, the experience is completely different. So, what you're going to see flee-- I mean, carefully see the user interaction. I mean, it looks fine as it is. Yes, the messages-- we've put a lot of thought in those messages.

So, now I'm trying to scroll and as you can see, I can-- I cannot even barely make it register my UI touch events because the main thread is busy waiting for those messages to come along and-- Oh, here. And you can see, I mean let alone the-- yeah.

Yeah. So, let alone the scrolling part, I mean, you cannot even barely register your UI touch events to even grab the screen. And that is what the experience would be like. You know, in the hands of a real customer where the network is not good and you're blocking the main thread and therefore, not letting it listen for events. OK. So, now, let's see what GCD can do for us.

So you have to believe me on this and we will show more examples as we go along. Is-- We took the same existing code base. We didn't add selectors. We didn't add more code into our existing code but simply used the existing code, wrapped it around with some basic simple GCD APIs and made our apps more responsive.

Again, from the look of it, it looks similar so if you're not doing any user interactions, you won't really see any difference but now let's see if we do the same kind of experiments of scrolling down and back, and there you go. And that's all we did.

Thanks. Alright.

So, what's the gist of the story? Like how to make your acts responsive? And this is probably something that you know but it's good to go over these. Well, one is never block the main thread. The main thread is there to display your UI and to listen for events. So, even though you might think that it's OK to do the nominal amount of work, it's not and it-- the nominal amount of work that you might think is OK would not be a nominal amount of work for your customers.

So, if you do not block the main thread, well you have to do that work on to some other thread. And what has been the case is the accessory code, the boiler plate code that you need to write to move that work from your main thread to a background thread is generally more than the actual work you want to do.

And then obviously once you have the result from the background thread, you want to show the result on the main thread and display it. And that has to be done on the main thread so you have to have a way to ship that result back from the background thread to the main thread. And we will show how you can do this with GCD. Very simply, again, without changing your existing code.

So, let's look at a code example here. You would imagine that's the naive way of doing it. You we're listening for tweets. You got the tweet message back and with that, you've got the profile URL from where you're supposed to get the profile image. The tweets were coming from a server.

The profile images were coming from an image server. So, that's the function that will be called on to your main thread. So here, you go ahead and add the tweet to your history of tweets. This is-- this lets us scroll the history of tweets as we were doing and we add the tweet and we say, you know, display it.

Then, and this is the bottleneck here, is we get the profile image from the image cache. Now, if it's there we would get it immediately. But if it's not there, it's actually going to get this image from the network and on a 3G network or an edge network, this is going to block.

And during this time when the main thread is blocked on this call, you are not responding to user interactions. This is why I was not able to even register those UI touch events as I was trying to grab the screen. And once you have the result, you want to update it.

And this is exactly why you do these things on the main thread because it's easy to update the result because you are already on the main thread. So now let's see how we can use GCD to simplify this. Again, as you will see no change to your code.

Well, some changes but no refractory.

So what we did is we enter this dispatch_async call and dispatch_async the quick and dirty way of thinking about it is that your just dispatch_asynching means roundness on the background. So, you take the Block of work that you were supposed to do and in this case, this is the work of getting the image which might block and you call dispatch_async. This frees up your main thread so your add tweet with message call is going to return and your main thread is free to again listen for events and display as they come along-- as the background thread is waiting for the image to show up.

Now, there you can block and the image will show up finally. But you want to update the image. So, beforehand, since you were on the main thread, you could just do it from the main thread without having to do anything. But now, this Block of code is running on the background thread and you have to do the update on the main thread. But we use the same trick again.

We call dispatch_async and here we call it on the main queue. The main queue is effectively in the dispatch while running things on the main thread. So, let's look at this in more details with a visualization which I think would help. So, here you have the main queue that is drained by the main thread and we have already realized that we want to get the image from URL block and not run it from the main queue.

So, we dispatch_async effectively entering that block onto this image queue that is going to run our background task. Now, note how GCD is efficient because as it-- as soon as it sees there is work to do an automatic thread comes along and starts executing that block. Your main thread is free so it can handle all these other events that are happening.

Your automatic thread executes. gets the result and then similarly end queues the update Block on to the main thread. And the main thread along its way is going to update the display. The automatic thread is done, executing the Block, it goes away. And your main thread finally updates your UI and you're back to having a single main thread. It doesn't hold on to that automatic thread. So, let's go back to the three main points that we had. We didn't want to block the main thread.

We wanted to move work from the main thread to a background thread, and we wanted to move the result from the background thread to the main thread, and we did all of these with dispatch_async. This is really the gist of GCD. I mean, this is a pattern that you will see over and over again.

You dispatch work from the main thread to a background thread and from the background thread, dispatch the result on to the main thread. So, now you have seen we have mentioned queues and I'm going to ask Daniel to talk about some of the more basics of dispatch queues.

Thank you, Shiva. I'm Daniel Steffen. I'm an engineer on the GCD team and I'd like to talk to you about the details of GCD queues today. So, you've probably seen in other sessions already mentioned of dispatch queues or GCD queues and these are really the fundamental concept in GCD that is really important to understand to use this technology effectively. So, what is a GCD queue? A GCD is actually a very simple lightweight list of blocks that you have committed for execution.

The enqueue and dequeue operations are FIFO and the enqueueing as we have seen happens when we call dispatch_async. This takes acute parameter and a block parameter and enqueues that block on to the queue. The dequeuing happens automatically for you on one of these automatic backgrounds threads that we've seen or on the main thread, depending on the queue type and its worth noting that's this dequeuing and running a Block is the only way that you can get a Block off a queue once you have dispatch_async the Block, it will run. You cannot stop that.

So, one queue type we've looked at already is the main queue and the main queue executes Blocks one at a time on the main thread and it cooperates with the UIKit main run loop which as you know is responsible for dealing with UI event and updating the UI. So, to get the main queue you call dispatch_get_main_queue. It's very simple. So, let's see an example of this in action.

So, remember these codes that we had before. This method that is a callback and adds a message to our user interface, this is a call back on the main thread. What do we need to do today with foundation to call this from an background thread probably something like this.

Here, we have a method that's called on the background thread with a message and a URL and we really want to do the thing at the very bottom of this slide which is called this addTweetWithMsg method on the main thread and all the rest on the slide is the body part that you have to do with foundation. You have to wrap up to two arguments in a dictionary, you have to call performSelectorOnMainThread with a special type of selector passing that dictionary.

You have to implement that special purpose selector, unpack the dictionary again taking the message and URL out, and then you can finally call your addTweetWithMsg. How can you improve this with GCD? Well, take away all the boilerplate and we call what we really want to call directly and we wrap this in a dispatch_async and that's it.

And as you can see here, we've used the dispatch kit main queue API to get the main queue which we passed as the first parameter to dispatch_async.

So these are the queues that we've seen that I mentioned that you can create yourself. So, these queues also execute blocks one at a time like the main queue and that's why you see them referred to as serial queues in documentation or in other sessions and the difference is that these execute their blocks on an automatic help as written in the background. And you can use this for instance to queue up some background work. So how do you create one of these queues?

You just call the dispatch_queue_create API and you pass in a text label. This can be anything you like but we recommend that you use the reverse dns notification that makes it very easy to identify and distinguish your queues from the queues that may already be present on the system and these are left in the Xcode debugger or in crash reports as well.

And when you're done with your queue, you call dispatch_release on it to a free the storage. So, there's much you can do with these queues. Bill has already mentioned just a bit earlier queues can be used instead of locks and why is this? The enqueueing operation that I mentioned is in fact thread-safe so it's perfectly fine to call dispatch_async on a queue from multiple threads at once and everything will work fine. And because the execution of locks is serial, is one by one, these two things combined allow you to protect access to a shared data structure by executing blocks on a queue and accessing the data structure only from those blocks.

And because queues are lightweight, this is actually easier and cheaper in many cases than using locking. You can imagine queues being an on demand locking mechanism that only creates a lock when there is contention and when a lock is really needed. So, let's see an example of this.

Imagine in our Twitter app, we have to maintain this history of tweets that we are displaying. This is a global object in our application and multiple threads wants to apply domain the background thread then gets new network messages and the main thread at displacement. So, we need to protect access to this shared resource somehow.

So, let's use a dispatch queue for this. So, we create a dispatch queue with dispatch_queue_create, give a nice label that tells us that this operates on these tweets object and then in the main thread wants to modify the object, say to remove the last item. It might be this too much history and we want to cut down on the history. We remove the last item. We dispatch_async to this queue and to block that executes can modify the shared DOC.

And then when the background display gets some new messages from the network, it also dispatch_async to this queue to add the new item and because queues execute these blocks one by one, the rest of those threads can be sure that once they're inside the block, they are the only ones operating on that shared object at that time and so, they can do safely without colliding. Also, note that we've used dispatch_async in both of these cases because the caller here doesn't actually care that this update happens right away. So, you don't need to block like you would be locking, and wait for this operation to finish before you can go on.

If you do want to block like in this case, we call dispatch_sync. That is exactly like dispatch_async except that they will wait for the block that it enqueues to finish executing before returning. So, here we would want to display the tweets, get a snapshot of the shared object and not refuse the __blocks syntax that you've seen earlier to extract the result from this block. And at the end, you call dispatch_release when you're done with the queue.

So let's see this in an animation. We have the main thread, the background thread, dispatch_queue that protects this shared object represented as a box. And these two threads enqueue some blocks and as you can see when they enqueue at the same time, they get enqueued safely in some undetermined order.

Here at the background thread one and its block that enqueued first. Now, the dispatch_queue has some work to do so an automatic thread comes along and runs these blocks and they can safely modify the shared resource because they know that they're the only ones executing a dispatch_queue at that time.

So, we remove an item, add an item, and the copy can take snapshots safely and update the main thread. And that's the end and there's no more block. The automatic thread goes away. So, now that you know how to create queues, you have to know how to manage their lifetime. So, as you have probably guessed queues are reference counted like other object types. And you use dispatch_retain/release to manage the reference code.

And note that GCD retains parameters to dispatch API. So, in many cases you don't actually have to do anything to manage this reference count. But if you have queues that get captured by blocks, you may have to do manual reference counting to ensure that lifetime of these queues is correct across asynchronous operations as we'll see in an example right now.

So, imagine in our Twitter app we have, want to-- asyncParse the data that we get from the network and extract the Twitter messages and we want this asyncParseData Objective-C method which takes the data and parses it. And when it has a result it calls back the user asynchronously and this is the pattern that Bill already mentioned.

The last parameter is a block that gets called, a callback block that the user gives us that we call when we're done and the queue that that block gets called on. So, here-- in here we will be calling a dispatch_async on a parse queue which will do the parsing on the, you know, on a background thread. And note that the block that gets enqueued here captures this queue parameter that the user gave us.

So, this is a case where you have to manually manage the reference cont of that queue object. Basically you can execute it after this method has returned and the caller may do anything they want with the queue at that point right? So you have to have a reference to the queue object to make sure that it's still there when the block actually gets executed. So, the way to do that is to call dispatch_retain on that queue object before calling the async with the block that captured it.

And inside that block, you can then call dispatch_release and you're done with it. So now that you've done that it's safe to async and we can parse our data and dispatch_async the result back to user provider queue and now we can release because as mentioned this dispatch_async is in an async retains its arguments so it retains that queue. So the pattern to remember is-- sorry-- the pattern to remember is to dispatch_retain before the async and release inside the block that captured the queue.

The same is true with other kinds of objects. In-- the general rule is that you have to ensure that objects that are captured by blocks are still valid when those blocks are executed and with dispatch_async that could be much later. So the good news is that as Bill has mentioned from objective-C objects you don't have to do anything and that would cover the large majority of your cases, these get auto retained and released by the blocks runtime and although it's just transparently, in our previous example for instance we have this NSData object we didn't have to manage the reference counts on that because the blocks runtime dealt with that for us.

However, if you have other objects like co-foundation objects, these need that same pattern that we saw they would see every time before an async and see a full list inside the block that gets async. So let's talk about doing App Design with Queues. So one pattern we recommend that you look at is to employ one queue per task or per subsystem in your app.

This will allow you to make these tasks very easily independent and communicate among them by using dispatch_async and because queues are very lightweight and efficient, it's not a problem to have many tasks and the associated queues. That doesn't mean that you will have many threads necessarily because in fact GCD does automatic thread recycling so one of these automatic threads that we saw could get used to execute blocks from many different queues during its lifetime.

So let's apply this idea to our demo. Essentially we have four tasks in this app, receiving and parsing the network stream, maintaining this shared message history object, fetching and caching images, and displaying the user interface. So how can we employ the one queue per task idea to this?

Well, the code in one thread for all these tasks might look like something like this, we get the data from the network, you parse it to create a tweet object, add this object to the shared storage, update the UI, then get the image from the imageCache and update the image display when we have received that and release it at the end.

So how can we use one queue per task to make these tasks independent? For the networking, as you can probably guess, we will dispatch_async to a queue that manages the network task and the network subsystem and as we've seen in the first part of the GCD section here, this will run potentially blocking like on a background thread.

Now when we have this data from the network, we will dispatch_async to the queue that manages the shared history object subsystem which we call tweets_queue here and from that-- inside that block when we need to update the UI, we dispatch_async to the queue that manages the UI subsystem which is the main queue and similarly for the imageCache, we dispatch_async to a queue that manages the imageCache subsystem and that can operate independently of the other paths and again from inside there when we have the image, we dispatch_async back to the main queue to update the UI.

So obviously this is a very simplistic contrived example but I'm sure you can imagine the power of this technique when applied to a complex application, here we've separated the code out with four queues and just used dispatch_async to communicate between the different subsystems. So there are some pitfalls to be aware of when you use this pattern, firstly, same as with the main queue, if you have this for subsystem queues, don't block them because if that's the way you communicate with the subsystem and you block that queue, you will block the whole subsystem.

Alright so the same technique applies to getting back off the main thread, you use another queue where you would push anywhere I think that would take a significant amount of time off too. And also when you use dispatch_sync API or other waiting API, be careful when you have many queues and multiple queues that you don't get into a deadlock situation. GCD doesn't protect you from the traditional mistakes you can make with multithreading and locking and if you do a dispatch_sync from one queue to another one which then dispatch_syncs back to the first queue, you will get into a deadlock. So that's something to be aware of.

Also if you block one of these automatic workers threads waiting on some external resource, this will actually make this pattern expensive where you said that dispatch queues were very efficient and lightweight but if all of those dispatch queues execute a block that waits since its there and parts one of these automatic worker threads you'll end up with many threads and that is actually expensive. So you can get into a situation like in this animation, here we have one queue that runs a block that cross a receive and it just never receives anything.

Maybe the network is slow and this will block this automatic thread in this receive block so if this happens with one queue that's not a big problem but if you have many queues and many occurrences of this and many automatic threads that get blocked, you can get into a situation where you will end up using a lot of memory and as you know on iOS if you do that, your app might get killed.

So one way around this problem is to use an API that allows you to respond to external events rather than having a blocking API that waits for something to happen and in GCD we provide one such API called dispatch_sources and we won't have time to go into this in a lot of detail today, we have a second session later on in the week that will cover this fully but just to give you an introduction, dispatch_sources allow you to monitor external event sources like files, like network sub groups, like directories, timers, very low-level things, and if an event happens on these sources, an event handler that you specified can be delivered to any queue you choose so this isn't like with the run loop sources that you might be familiar with where the event handling is tied to one specific thread and we recommend that you use these sources to replace any polling you are doing or blocking API calls for low level events and for more details, please come to the session Simplifying iPhone App Development with Grand Central Dispatch on Friday.

Just to give you a very quick teaser, remember this example with the many queues that we had before, here we have the dispatch_async to a network queue so this could be one of these examples where we might block one of the automatic threads waiting for networking communications to come in.

If you wanted to replace this with the dispatch source, all that we would need to do is to set up the source which we won't go into now, which will listen on a socket and then set the same block, the same code as the handler for that dispatch source and now, the source will trigger, will evoke this handler when there is actual network data on the socket so that we can immediately read it and don't have to wait and this will get re-invoked every time there is network data whereas before, with the async you would have had to do this every time to wait for more data as we process the last piece.

So where do I find this technology? The introduction already mentioned., GCD is part of loop system and that means that it comes along for free with malloc and other basic functionality, you don't have to do any special linking, it's available to all apps, you just include the header here, dispatch the edge, and you're good to go. Also worth mentioning, GCD's Open Source.

You can go to the libdispatch homepage on macosforge to get more details on that and there is also a mailing list where you can ask questions and for more information, please contact Michael Jurewitz, our development tools and performance evangelist. There is some very good documentation on the developer's side in particular the concurrency programming guide and there is extensive header DOC in the dispatch headers that you can look at as well as very good man pages on your Snow Leopard system which apply equally well to this technology on the iOS, and again the reference to the homepage on the Open Source site and on the Apple developer forums there is also a section labeled Core OS where you can ask questions about GCD and we have related sessions, on Friday the simplifying up an App development with GCD that has been mentioned this morning there was a working effectively with objective-C session that also talked about blocks briefly and there is an advance objective-C and garbage collection technique session on Friday after the GCD session. Alright, thanks for your attention.