iPhone multi-threaded AddressBook manipulation

Question

I have been using the AddressBook api of the iPhone for some time now. But doing some refactoring to improve application performance I have decided to "reuse" the ABAddressBookRef returned by AddressBookCreate because I noticed there are large performance improvements doing that. However, I am getting EXEC_BAD_ACCESS errors now randomly, and I think the reason is in this "caveat" in the iPhone reference implementation: http://developer.apple.com/iphone/library/documentation/ContactData/Conceptual/AddressBookProgrammingGuideforiPhone/300-BasicObjects/BasicObjects.html#//apple_ref/doc/uid/TP40007744-CH3-SW1

Important: Instances of ABAddressBookRef cannot be used by multiple threads. Each thread must make its own instance by calling ABAddressBookCreate.

Now, I thought that simply meant it was not thread-safe so I had to synchronise access to the API, but maybe I am wrong, and there is some other reasons multiple threads mess up the data structure?

Can someone confirm if it is indeed a thread-safe issue (so @synchronize should work) or some other issue?

Cheers

Keratogenous

Answer 1

This is not a thread safety issue... there is no way for you to solve it with locks. The comment makes it pretty clear:

Important: Instances of ABAddressBookRef cannot be used by multiple threads. Each thread must make its own instance by calling ABAddressBookCreate.

What you can do is create a single instance of the ABAddressBook and create a producer/consumer architecture that would manage the access to the object.

The wrapper will have a main thread which does one thing only: reads operation requests from a blocking queue, then performs the operations on the address book. All your threads will queue their operations to the single queue and the wrapper will execute those actions; if there is nothing in the queue then the wrapper will block until there is something in the queue.

This should solve the problem of not being allowed to use the ABAddressBookRef from multiple threads.

Kazue

Hi Lirik, yes, I have gotten to the same conclusion... it seems like a very bad way to build an AB framework to be honest.. the developer is left to build a (relatively) complex multithreaded solution to solve a common problem that should be architected, but what can one do.. I am going to have to wheel in the big guns and do it the hard way.. thank you! – Keratogenous

Actually, I had built a different solution before reading your answer, where i kept a dictionary of ABRefs with thread names thinking (naively) that the iPhone recycles threads from a threadpool... but helas, no dice... it builds a new thread every time you detach one... so I had finally gotten to your same conclusion – Keratogenous

@Lirik and @Marko, I have the same problem. I have already seen the multi-threading issue and have implemented the AB wrapper pretty from the beginning. But I still have a huge bug - sometimes the app crashes and sometimes it deletes all the contacts from the AB. I have tripple-checked that all the methods that use AB instance do it from the thread that is managed by this wrapper. – Pulpboard

Is there a chance that the use of ABContactRef that was retrieved from an AB also should be done from the same thread? In general, I read the contacts, compare them to the ones inside my app's CoreData DB and. If there are changes then I update the Core Data objects, if there are additions then I add them to the local Core Data DB etc. Any help will be more than appreciated. Thank you. – Pulpboard

@Michael, unfortunately I'm not very familiar with Apple programming... I only answered that question because I'm familiar with threading. It looks like a more "in-depth" issue and I'd suggest you ask it as a separate question. – Kazue

@Michael, according the documentation you cannot (or should not) pass record references across threads, either. Instead, pass identifiers (e.g. ABRecordGetRecordID). If I were to guess, I'd say this is because they reference for the ABAddressBookRef internally. – Klecka