mikeash.com pyblog/friday-qa-2009-09-18-intro-to-grand-central-dispatch-part-iv-odds-and-ends.html comments

Pitiphong Phongpattranont - 2013-09-20 11:24:10

Fri, 20 Sep 2013 11:24:10 GMT

FYI https://devforums.apple.com/message/893877#893877

Pitiphong Phongpattranont - 2013-09-18 15:13:18

Wed, 18 Sep 2013 15:13:18 GMT

I'm curious about dispatch_barrier and the target queue. What happen when I dispatch_barrier blocks on the queue that targeted on the concurrent queue? Will I block the execution of the blocks submitted to the targeted queue too? Or if I dispatch_barrier blocks to the concurrent queue, will it block the execution of the blocks in the child queue?

mikeash - 2009-09-21 02:30:37

Mon, 21 Sep 2009 02:30:37 GMT

The first two do not. They are documented as setting up a timer in the current runloop, which GCD can't currently do. Until and unless GCD becomes the foundation for CFRunLoop, these won't involve GCD.

The last one almost could, except that it's documented as creating a new thread. Code using that method could expect that they own the thread that their code executes on and might do things that GCD doesn't like (you're not allowed to do things like mess with your thread's priority, kill the thread, etc. while executing on a GCD thread) so Apple couldn't really change that one either.

Christophe Braud - 2009-09-21 02:01:00

Mon, 21 Sep 2009 02:01:00 GMT

With NSObject we have some functions like

- performSelector:withObject:afterDelay
- performSelector:withObject:afterDelay:inModes
- performSelectorInBackground
...

these functions are implemented with GCD too?

mikeash - 2009-09-19 00:18:58

Sat, 19 Sep 2009 00:18:58 GMT

Axel Andersson: A fine question, and one I asked myself as well when I saw that macro. You'll find the answer to that question in a comment in the source code which implements the one-time initialization functionality:

http://libdispatch.macosforge.org/trac/browser/trunk/src/once.c

Scroll down to where it reads "The next barrier must be long and strong" and go from there.

The summary is that raw double-checked locking has problems because you need memory barriers to make sure all threads see changes happen in the right order. Normally you need both read and write barriers. What the dispatch guys figured out was that you don't need read barriers if the write side ensures that enough cycles occur between the initialization and the signal that it's impossible for any reader to have performed an out-of-order read that sees the one but not the other.

In other words, modern CPUs perform out-of-order reads only in close temporal proximity. By waiting a few cycles before writing to the shared flag, they ensure that any CPU which sees the shared flag as being set will also have seen all initialization take place. This allows them to get away with only a write barrier, and no read barrier.

Stuart Dootson: Blocks don't work on previous versions of OS X by default, because they need a runtime library. It's not substantial, but it is required. Don't let C++0x lambdas trick you; Apple's blocks are a lot more capable in ways that require additional runtime support. (Namely, they can persist beyond the scope that created them, and they need to manage memory in order to make that happen.)

There is a third-party blocks runtime (built using Apple's source code) and associated compilers available called PLBlocks. More details on that here:

http://www.mikeash.com/?page=pyblog/friday-qa-2009-08-14-practical-blocks.html

Stuart Dootson - 2009-09-19 00:05:35

Sat, 19 Sep 2009 00:05:35 GMT

Mike - a question about blocks (kind of tangential, as this series, which has been very informative, has been about GCD, but GCD does use blocks extensively…):

If you know….

Is code using blocks (not GCD, just blocks) runnable on previous versions of OS X? Is there a dependency on Snow Leopard's version of the C run-time or something?

I'm wondering, because knowing how lambdas are implemented in C++0x (as function objects), it seems like blocks shouldn't require tooo much in the way of run-time support?

Axel Andersson - 2009-09-18 22:59:22

Fri, 18 Sep 2009 22:59:22 GMT

For dispatch_once, I'm curious whether the use of an initial inline test constitutes double-checked locking, or if there are any protections against that.