mikeash.com pyblog/friday-qa-2009-09-04-intro-to-grand-central-dispatch-part-ii-multi-core-performance.html comments

Andrew Rahn - 2014-09-23 16:11:17

Tue, 23 Sep 2014 16:11:17 GMT

Mike -- you have a typo above. Search for dispatch_get_global_qeueue (extra e in queue).

cristik - 2014-05-30 20:54:45

Fri, 30 May 2014 20:54:45 GMT

Karty, is downloadImageFromRemotePath: using NSURLConnection or NSURLDownload? If yes, are you using the sync or async calls? If async, what kind of work are you doing within the delegate methods?

Karty - 2013-11-20 06:59:09

Wed, 20 Nov 2013 06:59:09 GMT

I don't understand why the below code is blocking. Here I'm downloading a list of images and once all the images are downloaded the tableview should be reloaded. As it needs to update the UI I dispatch this async in the main queue. But this code blocks the UI.



dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);

    dispatch_async(dispatch_get_main_queue(), ^{

        dispatch_apply([self imageList].count, queue, ^(size_t index) {

            [self downloadImageFromRemotePath:[[_imageList objectAtIndex:index]];

        });

            [[self tableView] reloadData];

    })

Stuart Carnie - 2009-10-01 18:32:38

Thu, 01 Oct 2009 18:32:38 GMT

Great post Mike - thanks for the information!

jamiehardt - 2009-09-10 20:22:53

Thu, 10 Sep 2009 20:22:53 GMT

Thank you for posting on GCD, there's still very little practical lit on it on the webs and these demonstrations are much more edifying than Apple's.

mikeash - 2009-09-10 16:41:31

Thu, 10 Sep 2009 16:41:31 GMT

Do not confuse thread safe with reentrant. They are somewhat similar but markedly different concepts.

What you're describing is actually thread safety. Multiple independent threads of control, executing simultaneously (possibly time-sharing CPUs, but conceptually simultaneously) in the same block of code. If that block of code is thread safe, then operations complete as expected in this circumstance. If it is not thread safe, then the threads interfere with each other and Bad Things Happen. The common way to make a block of code thread safe is to wrap it in a lock, which allows only one thread into unsafe areas at a time.

Reentrancy is very different. Click your click, then in the table of contents click "Appendix A: Thread Safety Summary". Notice how there are separate sections listing thread-safe classes and reentrant classes.

Reentrancy is allowing the same thread of control to call a block of code while that block of code is already being executed farther up the stack.

As an example, take one of the reentrant classes listed on that page: NSNotificationCenter. Imagine that some code posts a notification, which is then received by your code. One stack frame up from your code, NSNotificationCenter is sitting in the middle of some of its code. From within your notification handler, you decide to add a new notification observer, calling back into NSNotificationCenter even though it's still in the middle of executing.

Reentrant means that NSNotificationCenter can handle this situation.

Imagine if NSNotificationCenter took an NSLock at the beginning of every method, and relinquished it at the end. It would be thread safe. But the scenario I outlined above would deadlock. It would not be reentrant.

Another, less common scenario where reentrancy is important is in signal handlers. A signal handler is executed by essentially hijacking a thread in your application and making it run the signal handler. Whatever that thread was doing at the time is just paused for the time being. Lots and lots of thread-safe APIs are completely unsafe to call from a signal handler, because those APIs achieve thread safety through locks, and the thread that was hijacked to run the signal handler may well be holding onto one of those locks, leading to a deadlock.

To put it simply, reentrancy is basically about being thread-safe when all but one of the threads are blocked for the duration, whereas normal thread safety is about being safe when all of your threads are actively executing.

Most of what you say is correct, as long as you think "thread safe" every time you read "reentrant".

jamiehardt - 2009-09-10 07:12:05

Thu, 10 Sep 2009 07:12:05 GMT

Hmm, maybe I'm confused... Need to do more reading.

jamiehardt - 2009-09-10 07:05:24

Thu, 10 Sep 2009 07:05:24 GMT

Just to add to the general thread-safety convo -- the basic idea is that your code should be "reentrant," which means if process 1 enters your block of code, and then process 2 enters your block of code with a different set of arguments, they should both be able to play back all of the instructions in that block without messing with each other's business.

Think of your code block (in a selector implementation, or a function, or whatever) as a recipe and the scope it runs in is a kitchen. If you were to give this recipe to two blind cooks at the same time, does the recipe give them enough information so they don't accidently set the oven to 900 degrees, or one adds flour to a cake that's already iced, because you store a finished cake and the mixing bowl on the same counter? A "lock" in this instance is like a step in the recipe that says "feel the counter, if it is occupied, wait until it isn't, otherwise proceed." This way, two cooks can work in the kitchen simultaneously and share the counter -- the first will get it first, but the second only has to wait until the cook is done with the counter, and then the first cook will "relinquish" it and take over the oven, meaning the second can get to work with the counter and then wait for the oven to be available.

Also on a more concrete note, there's a bit of reading you should do about the reentrancy of the various Apple APIs, because not all of them are, and putting many Cocoa API calls inside an async block will fail horribly -- mikeash has already gone into this a little. AppKit is basically not reentrant: bits of it are, but anything inheiriting from NSResponder or NSView isn't, and that's most of AppKit. The Foundation API is, except for things like NSArchiver, the mutable collection classes, and host of other things. So keep in mind that if you are trying to write thread-safe code, not only does it have to be internally thread-safe, but anything you call must be thread-safe as well.

http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Multithreading/Introduction/Introduction.html

mikeash - 2009-09-08 21:26:30

Tue, 08 Sep 2009 21:26:30 GMT

I should also note that having the setter run asynchronously means you need to ensure that you're working with thread safe data in the setter.

For example, if you have an NSString setter that makes a copy of the string (to avoid sharing an NSMutableString) then you should make the copy outside of the setter block, so that it happens synchronously with the caller. Once you have the copy, you can then enqueue a block to actually set your instance variable to point to that copy.

Put it another way: using locks means that setters happen synchronously with respect to both the caller and the callee. Using an asynchronous dispatch means that part of the setter happens synchronously only with respect to the caller, and part of it happens synchronously only with respect to the callee. For many things this makes no difference, but for some things you will have to split code between the two regions. This is similar to how the synchronous getter had to call autorelease outside the dispatch block to ensure that it happened on the correct thread.

mikeash - 2009-09-08 21:03:04

Tue, 08 Sep 2009 21:03:04 GMT

A good question. Maybe I'll expand on it in a future edition of Friday Q&A if you want to call this a topic suggestion, but here's the short version.

A thread safe API needs to follow three rules:

1) Synchronize all access to shared data. In other words, always take a lock (or something equivalent, like using a serial dispatch queue) before touching any shared state.

2) Ensure that the visible state of the object is self-consistent at all times. E.g. you have separate firstName and lastName variables, you should always update them both within a single critical region so that a change from "Charlie Chang" to "Mohammed Ali" doesn't result in some poor caller getting a full name of "Mohammed Chang".

3) Ensure that the visible state of the object is temporally consistent from any given thread. In other words, if you set, and then get (and no other thread jumped in the middle) the get should reflect the set.

(I may have forgotten some rules, since this is off the cuff, but consider these to be at least a minimum.)

Using locks around shared data gives you 1 and 3 automatically. #2 you have to work at by making sure that all of your updates are done atomically. (Incidentally this is why the atomic attribute on ObjC @property declarations is such a bad idea; it fools you into thinking that you're safe but does nothing to achieve #2.)

So what do dispatch queues give us?

#1 is taken care of because the dispatch queue acts just like a lock if you ensure that all shared data access occurs on the queue.

#2 is up to you, just like it is with locks. Ensure that your object's internal state is consistent every time you exit a block on your dispatch queue.

#3 is probably what you're worried about. However, the use of a serial queue, and the fact that GCD guarantees that queues execute in FIFO order, ensures that this is always taken care of. Your setter executes asynchronously, this is true. However, it is guaranteed to execute before any subsequent operation. The danger would be in having a getter, enqueued afterwards, run before the setter has a chance. But this can't happen; if the setter hasn't run yet, the getter will be blocked until it has, at which point the getter will see a temporally consistent value.

Nat - 2009-09-08 18:51:22

Tue, 08 Sep 2009 18:51:22 GMT

This series is shaping up great; it's highly evocative. Thanks.

Going back to the first part, can you elaborate on use of GCD in lieu of locks? A setter which returns immediately and does its work asynchronously seems like a race condition waiting to happen.

I presume I'm missing something -- all threaded programming sort of seems like a race condition waiting to happen -- but I was surprised to see that option presented matter-of-factly.

Nick - 2009-09-05 16:40:28

Sat, 05 Sep 2009 16:40:28 GMT

Excellent, much more helpful than the apple dev website(link to GCD is broken atm)