Does GCD assure that all the blocks working in the same queue are always working in a same thread?(About ABAddressBookRef)

Does GCD assure that all the blocks working in the same queue are always working in a same thread?

If I create a dispatch queue and dispath_async blocks to this queue, does all the blocks that dispatch to that queue works in the same thread?

Since I'm working on a project that uses ABAdrressbook Framerowk and the document says that ABAddressBookRef and ABRecordRef can't be used between threads, so I wonder if all the blocks in the queue are in the same thread, I can create only one AddressBookRef开发者_StackOverflow社区 for that queue.

---

The only queue bound to a specific thread is the main queue, which is bound to the main (UI) thread.

If the only requirement is not to concurrently access the object, using a serial queue should work fine.

If the object instead relies on thread-local state, you will have to force all manipulation to a specific thread. The easiest would be to target your serial queue to the main thread, but that only works if you know you're not going to be stuck for long in the block; otherwise, you will hang your UI. In that case, you'll have to create your own handler thread and send the work over there.

---

• dispatch_queue_create(3) Mac OS X Manual Page

Queues are not bound to any specific thread of execution

There is no guarantee that all blocks sent to a serial queue are sent to the same thread. And I couldn't find any source code for combination of ABAddressBookCreate with GCD Serial Queue...

---

When the documentation says that something can't be used between threads, it only means that the API can't be used concurrently from different threads at the same time. The API itself doesn't remember anything special about the thread calling it or something like that and forcing it to be the same each time.

Previous to GCD you would serialize access to a shared resource with @synchronize. As you suggest yourself, creating a queue for this is another way of serializing access to this resource which is more efficient.