Гарантирует ли GCD, что все блоки, работающие в одной и той же очереди, всегда работают в одном потоке? (О ABAddressBookRef)

Question

Гарантирует ли GCD, что все блоки, работающие в одной и той же очереди, всегда работают в одном и том же потоке?

Если я создаю очередь отправки и блоки dispath_async для этой очереди, все ли блоки, которые отправляются в эту очередь,очередь работает в том же потоке?

Поскольку я работаю над проектом, использующим ABAdrressbook Framerowk, и в документе говорится, что ABAddressBookRef и ABRecordRef нельзя использовать между потоками, поэтому мне интересно, все ли блоки вочереди находятся в одном потоке, я могу создать только одну AddressBookRef для этой очереди.

Answer 1

Единственная очередь, связанная с конкретным потоком, - это основная очередь, которая связана с основным потоком (UI).

Если единственное требование - не одновременный доступ к объекту, использование последовательной очереди должноработает нормально.

Если объект вместо этого полагается на локальное состояние потока, вам придется принудительно переместить все манипуляции в определенный поток.Проще всего было бы нацелить вашу последовательную очередь на основной поток, но это работает, только если вы знаете, что не будете долго задерживаться в блоке;в противном случае вы повесите свой пользовательский интерфейс.В этом случае вам придется создать свой собственный поток обработчика и отправить работу туда.

Answer 2

• dispatch_queue_create (3) Страница руководства Mac OS X

Очереди не связаны с каким-либо конкретным потоком выполнения

Нет гарантии, что все блоки, отправленные в последовательную очередь, будут отправлены в один и тот же поток.И я не смог найти никакого исходного кода для комбинации ABAddressBookCreate с GCD Serial Queue ...

Answer 3

Когда в документации говорится, что что-то нельзя использовать между потоками, это означает только то, что API нельзя использовать одновременно из разных потоков одновременно. Сам API не помнит ничего особенного в том, что поток вызывает его или что-то в этом роде и заставляет его каждый раз быть одним и тем же.

До GCD вы бы сериализовали доступ к общему ресурсу с помощью @synchronize. Как вы сами предлагаете, создание очереди для этого является еще одним способом сериализации доступа к этому ресурсу, который является более эффективным.