Grand Central Dispatch: очередь против семафора для контроля доступа к структуре данных?

Question

Я делаю это с Макруби, но я не думаю , что здесь должно иметь большое значение.

У меня есть модель, которая хранит свое состояние в структуре данных словаря.,Я хочу, чтобы параллельные операции периодически обновляли эту структуру данных.Мне кажется, что GCD предлагает несколько возможных решений для этого, в том числе эти два:

• обернуть любой код, который обращается к структуре данных в блоке, отправляемом в некоторую последовательную очередь
• useсемафор GCD, с клиентским кодом, отправляющим вызовы ожидания / сигнала по мере необходимости при доступе к структуре

Когда очереди в первом решении вызываются синхронно, тогда это кажется в значительной степени эквивалентным решению семафора.Есть ли у одного из этих решений явные преимущества, которые я упускаю?Есть ли лучшая альтернатива, которую я упускаю?

Кроме того: было бы просто реализовать блокировку чтения-записи (совместно-эксклюзивную) с помощью GCD?

Answer 1

Защита доступа к структуре данных с помощью dispatch_sync в последовательной очереди семантически эквивалентна использованию семафора диспетчеризации, и в неконтролируемом случае они должны быть очень быстрыми. Если важна производительность, сравните результаты и посмотрите, есть ли существенная разница.

Что касается блокировки чтения-записи, то вы действительно можете сконструировать ее поверх GCD - по крайней мере, на днях я что-то скомбинировал здесь , что, похоже, работает. (Предупреждение: там могут быть драконы / плохо проверенный код.) Мое решение направляет запросы на чтение / запись через промежуточную последовательную очередь перед отправкой в ​​глобальную параллельную очередь. Последовательная очередь приостанавливается / возобновляется в соответствующее время, чтобы гарантировать, что запросы на запись выполняются последовательно.

Я хотел что-то, что имитировало бы частную очередь параллельной отправки, которая учитывала бы точки синхронизации - что-то, чего нет в общедоступном API GCD, но настоятельно намекает на на будущее.

Answer 2

Добавление предупреждения (которое в конечном итоге является аргументом для очередей отправки) к предыдущим ответам.

Вы должны быть осторожны с тем, как вызываются очереди отправки, поскольку есть некоторые скрытые сценарии, которые не были очевидны для меня сразу, пока я не столкнулся с ними.

Я заменил NSLock и @synchronized на ряде критических секций с очередями отправки с целью облегченной синхронизации. К сожалению, я столкнулся с ситуацией, которая приводит к тупику, и я вернул его обратно к использованию шаблона dispatch_barrier_async / dispatch_sync. Казалось бы, dispatch_sync может случайно вызвать свой блок в главной очереди (если он уже выполняется там), даже когда вы создаете параллельную очередь. Это проблема, поскольку dispatch_sync в текущей очереди отправки вызывает тупик.

Полагаю, я буду двигаться в обратном направлении и использовать другую технику блокировки в этих областях.

Answer 3

Serial Queue

• Pros
  • нет блокировки
• Cons
  • задачи не могут работать одновременно в последовательной очереди

Семафор GCD

• Pros
  • задачи могут работать одновременно
• Cons
  • он использует замок, хотя и легкий

Также мы можем использовать атомарные операции вместо семафора GCD. В некоторых ситуациях он будет легче семафора GCD.

Инструменты синхронизации - атомарные операции