I often use dispatch queues for locking, and this function just makes life SO MUCH EASIER. Accidental deadlocks in more complex code paths are a PITA otherwise. But Apple deprecated dispatch_get_current_queue with iOS6?

gistfile1.c

nline void pspdf_dispatch_sync_reentrant(dispatch_queue_t queue, dispatch_block_t block) {
    dispatch_get_current_queue() == queue ? block() : dispatch_sync(queue, block);
}

dispatch_get_specific can be used to get the value of a key that was attached to the tree of queues. That lets you know where you are in the queue tree and whether it is safe, from your design's standpoint, to run synchronously. iOS 5.0+

@ctp That's extremely disappointing. It's already hard enough to use synchronous dispatches in any safe way, and I've written a lot of code to make this pattern scale (and behave more predictably): https://github.com/jspahrsummers/SafeDispatch

@jspahrsummers - Disappointing? It's part of the dispatch_sync() contract and makes sense if you think about what's happening with respect to the queue.

I'm not sure what to tell you relative to your SafeDispatch project - I'm afraid I don't have the time right now to go through and figure out what to recommend if this pattern appears there.

The man page for dispatch_sync() describes one approach to the problem if you must use a recursive locking pattern; perhaps that's something which might help out (I don't know).

@ctp I agree that it's part of the contract, and does violate ordering, but, in my opinion, such issues are preferable to deadlocks. All of these problems are difficult to verify statically (with a compiler or as a human), so it's really a question of which failure you would rather have.

I could see an argument either way, honestly, which sounds to me like it should be up to the caller. GCD is already a fairly low-level API – I think allowing users to make decisions like this fits with its design.