Internal locking behaviour of Objective-C blocks?

[Michael Tyson]

Hello,

I'm pondering the viability of using ObjC blocks in a realtime Core Audio thread context.

I go to extensive measures to avoid any kind of blocking code in the Core Audio thread, and that includes avoiding making Objective-C calls, as the message sending system does do some internal locking, and thus could block the thread.

I'm wondering if this also applies to the use of blocks - assuming of course, the implementation contained within the block itself doesn't do any blocking or Objective-C method calls.

Does performing a block...block?  Does it use an internal mutex, which could end up holding up the realtime thread? Is there any other reason to avoid blocks in a realtime context?

Many thanks,

Michael

-- 
Michael Tyson | atastypixel.com

Live, app-to-app audio streaming is coming soon.
Don't want to miss our launch? Then sign up here: http://audiob.us

[Jim Dovey]

A block compiles down to a single method call. Copying a block to the heap will copy any referenced variables, so if it captures an ObjC object you'd need to ensure that object's -copy implementation didn't block. But calling a block itself just compiles down to a call instruction, so no blocking or locking behavior there.

Sent from my iPhone

[Michael Tyson]

Well - that's excellent news!

So, in that case, as long as the actual management of the block's lifespan (copy, release, etc - which may do mutex stuff) is performed outside the realtime context, the block perform call itself should presumably be perfectly fine, in the context of Apple's "don't block" guidelines.

Thanks heaps,

Michael

-- 
Michael Tyson | atastypixel.com

Live, app-to-app audio streaming is coming soon.
Don't want to miss our launch? Then sign up here: http://audiob.us

[Thomas Clement]

Referenced ObjC objects are retained, not copied.

Thomas

[Michael Ash]

On Aug 31, 2012, at 8:44 AM, Jim Dovey <jimd...@gmail.com> wrote:

> A block compiles down to a single method call. Copying a block to the heap will copy any referenced variables, so if it captures an ObjC object you'd need to ensure that object's -copy implementation didn't block. But calling a block itself just compiles down to a call instruction, so no blocking or locking behavior there.

A block call is a single *function* call. When you write block(...), it compiles down to code that does block->implFptr(block, ...), where block is conceptually a struct, and implFptr is a member containing a function pointer to the block's actual code. Unlike ObjC method calls, there's no way this code can block short of the memory it depends on being paged out. (ObjC message sends can potentially take locks, although it's extremely rare.)

Copying a block in the render callback would be bad regardless, as the memory allocation alone is something you'd want to avoid. But assuming you copy it beforehand, it's perfectly safe to call as long as the contents are safe.

Mike

[Michael Tyson]

Lovely, thanks for the reassuring clarification, Mike. I've revised my implementation and it's working splendidly with blocks now.

(It's a mechanism I've build into my audio engine that allows me to synchronise between the Core Audio thread and other threads, without needing locks.) So:

- (void)performSynchronousMessageExchangeWithBlock:(void (^)())block;

- (void)performAsynchronousMessageExchangeWithBlock:(void (^)())block

                                      responseBlock:(void (^)())responseBlock;

For sending messages to the Core Audio thread, and

void AEAudioControllerSendAsynchronousMessageToMainThread(AEAudioController                 *audioController, 
                                                          AEAudioControllerMainThreadMessageHandler    handler, 
                                                          void                              *userInfo,
                                                          int                                userInfoLength);

for sending messages back to the main thread; both based upon a lock-free circular buffer.

Working very nicely now with blocks - a lot easier than what I was doing before, which was using a C function pointer and userInfo, like the third method above.