Why would ABAddressbookRef need to be created for each thread?

Apple says:

Important: Instances of ABAddressBookRef can not be used by multiple threads. Each thread must make its own instance.

But why?

I know that some particular class or operations must be done in main thread.

And I know some objects ar开发者_C百科e not thread-safe (which means it would cause problem if these objects are accessed by two different threads concurrently).

But, if you can make sure that the the thread-unsafe objects are accessed by only one thread at any moment, then there should be no problem.

Do I understand correctly thus far?

What I can't understand is, Why would some objects like ABAddressbookRef need to be created for each thread? Why would Apple say something like this? If it's just that it's thread-unsafe, Apple can says it's thread-unsafe, be careful when handling it. But why is there a need to create one for each thread? Is there any reason that I don't know?

Does the implementation of ABAddressbookRef rely on the thread which created it?

PS: I remember that Core Data also says ManagedObjectContext need to be creates for each thread which uses it.

---

To put an end to the speculation I used paid support to ask Apple for a definite answer regarding ABAddressBookRef and multiple threads.

Here is what I asked:

There has been a lot of speculation on the matter and I decided I would like to ask for a definite answer from an engineer who is well aware of the implementation details of ABAddressBook Framework.

The documentation states: Important Instances of ABAddressBookRef cannot be used by multiple threads. Each thread must make its own instance.

If I take this literally, it means that ABAddressBookRef must be created in each block even with GCD serial queues since GCD does not give any guarantees about threads beside the global main thread.

I want to ask if this is literally how it is meant, OR, is it enough to ensure that no two threads are accessing the same ABAddressBookRef at the same time at any moment which GCD private serial queue does guarantee.

And here is what I got in return from Apple.

Thank you for contacting Apple Worldwide Developer Technical Support. I am responding to let you know that I have received your request for technical assistance. That is correct. This is because an address book object should never cross thread boundaries. As such, each block must have its own instance.

This is bad news.

---

But if you can assure the the thread-unsafe objects is only accessed by one thread at any moment, then there would be no problem.

Yeah, and that's exactly what Apple tells you to do:

Instances of ABAddressBookRef can not be used by multiple threads

The reason, as you pointed out, is that those ABAddressBookRef objects (actually c structs) are not thread safe. You could also add locks to ensure not two threads are accessing (for read of write) a ABAddressBookRef at the same time, using @synchronized(addressBookRef) { }