blocks, function pointers

OK. I would like to talk about the block. By now, I believe that many of you heard of “block” introduced in Objective-C 2.0 for Snow Leopard. Before Snow Leopard, even though it is Objective-C 2.0, block was not included. ( or hidden? ) There are 3rd party group of people who announced gcc compiler with block for pre-Snow Leopard, though.

Well, is it a new concept? No, it is not. In JavaScript, there is already one, called closure. In Java, they introduced “closure” from certain version of the Java. In Ruby, there is also closure.
In Python, yeah.. there is also. ( right? If I remember correctly. )

Sometimes it is called lambda functions. If you take a look at the Visual Studio 2010, you can notice that they mentioned “lambda” function. So, whatever the name is, i.e. block, closure or lambda function, they are all the same.

OK. Let’s take a look at how block looks like.

int (^oneFrom)(int);

oneFrom = ^(int anInt) {
    return anInt - 1;

printf("%d\n", oneFrom(10));

Hmm. So, here the oneFrom is a block. So, a block called oneFrom is declared and defined. And it is used in somewhere else like the last line.

Hmmm… Second thought…
Isn’t it same to function pointer? Yes, it is. Even in Apple’s document, it describes so. Then why should we have another “same” mechanism?

In my opinion, it is about “object-fied” function. Although they look same or similar, except for the ^, they are slightly different. function pointer is just an alias to funciton, while block is an object. So, an object can be transferred to anywhere else. Like different core, different CPU, different thread, and so on. What you can achieve with block is almost same to what you can do with function pointer in most cases. However, one difference is that, you are almost free from synchronization issue, because each incident of block are independent object, and it can be transferred to other processing unit. Although block is a stack based, but it can be also copied to heap using Block_copy() call. So, it is flexible.
Anyway, to me the crucial difference between the two is whether it is object or not.

The reason Apple picked block for concurrent programming seems to that it can be easily transferred to different CPUs or cores, because they are independent object.
You are transferring not only data but also “logic”.

With introduction of SIMD processing, data have been distributed to different processing unit at once, and they are operated at the same time. However, this time, due to block, even logic is distributed to other units!

The NSOperation in Snow Leopard is said to utilize blocks. It is very reasonable idea if we understand the nature of block. Probably it could be also done with function pointers, but because function pointers points to same location, and thus shared by other threads, it would be difficult to make things more concurrent. And there nightmare of dealing synchronization values like semaphore starts.

I’m not saying that we can eliminate synchronization by using blocks. There are still many situation where we need synchronization. For those, thread will be still used. However, programmers had have difficulty in managing thread and synchronization variables. By introduction of blocks, many cases where synchronization are required could be eliminated.

Next time, I would like to talk about thread management and operation queue.
( will also go further with GCD and OpenCL )

NOTE : block is not only available to Objective-C. It is also available for C and C++. What is interesting is that it is still Objective-C object.

cf. Reason : Why blocks? from Cocoa for Scientists

Why Blocks?
Why is all of this important, and why now? Well, as you are undoubtedly aware, there has been a vicious war raging the last few years, and it is only going to get worse before it gets better. That’s right — it’s the War on Multicore.
Our chips no longer get faster, they just get more abundant, like the broomsticks in Disney’s Fantasia. Chipmakers just take existing designs, and chop them in half, and then in half again, and software developers are expected to do something useful with that extra ‘power’.
It turns out that blocks could be a very useful weapon in the War on Multicore, because they allow you to create units of work, which each have their own copy of the stack, and don’t step on each others toes as a result. What’s more, you can pass these units around like they are values, when in actual fact they contain a whole stack of values (pun intended), and executable code to perform some operation.
In fact, blocks could be seen as a low-level form of NSOperation. For example, if you are parallelizing a loop, you could easily generate blocks for each of the iterations in the loop, and schedule them to run in parallel, in the same way that NSOperationQueue does this with instances of NSOperation. The advantage of blocks is that they are at a lower level, built into the language, and require much less overhead. Stay tuned, because Apple undoubtedly has some big things planned along these lines in Snow Leopard.


One response to this post.

  1. […] Blocks, Function pointers […]


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: