Атомарные операции

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

OS X и iOS включают многочисленные операции для выполнения основных математических и логических операций на 32-разрядных и 64-разрядных значениях. Среди этих операций атомарные версии сравнивать-и-подкачивать, теста-и-набора и операций тестировать-и-очищать. Для списка поддерживаемых атомарных операций посмотрите /usr/include/libkern/OSAtomic.h заголовочный файл или видит atomic страница справочника.

Барьеры памяти и энергозависимые переменные

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

Барьер памяти является типом неблокирования инструмента синхронизации, используемого, чтобы гарантировать, чтобы операции памяти произошли в правильном порядке. Барьер памяти действует как предел, вынуждая процессор завершить любую загрузку и операции хранилища, расположенные перед барьером, прежде чем будет позволено выполнить загрузку и операции хранилища, расположенные после барьера. Барьеры памяти обычно используются, чтобы гарантировать, чтобы операции памяти одним потоком (но видимый другому) всегда произошли в ожидаемом порядке. Отсутствие барьера памяти в такой ситуации могло бы позволить другим потокам видеть на вид невозможные результаты. (Для примера см. статью в Википедии для барьеров памяти.) Для использования барьера памяти Вы просто вызываете OSMemoryBarrier функция в надлежащей точке в Вашем коде.

Энергозависимые переменные применяют другой тип ограничения памяти к отдельным переменным. Компилятор часто оптимизирует код путем загрузки значений для переменных в регистры. Для локальных переменных это обычно - не проблема. Если переменная видима от другого потока, однако, такая оптимизация могла бы препятствовать тому, чтобы другой поток заметил любые изменения в нем. Применение volatile ключевое слово к переменной вынуждает компилятор загрузить ту переменную из памяти каждый раз, когда это используется. Вы могли бы объявить переменную как volatile если его значение могло бы быть изменено когда-либо внешним источником, который компилятор может не быть в состоянии обнаружить.

Поскольку оба барьера памяти и энергозависимые переменные сокращают число оптимизации, которую может выполнить компилятор, они должны использоваться экономно и только там, где это необходимо для обеспечения правильности. Для получения информации об использовании барьеров памяти посмотрите OSMemoryBarrier страница справочника.

Блокировки

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

Таблица 4-1 перечисляет некоторые блокировки, обычно использующиеся программистами. OS X и iOS обеспечивают реализации для большинства этих типов блокировки, но не всех их. Для неподдерживаемых типов блокировки столбец описания объясняет причины, почему те блокировки не реализованы непосредственно на платформе.

Для получения информации о том, как использовать блокировки, посмотрите Используя Блокировки.

Условия

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

Одним путем Вы могли бы использовать условие, должен управлять пулом незаконченных событий. Когда были события в очереди, очередь событий использовала бы условную переменную для сигнализации потоков ожидания. Если бы одно событие поступает, очередь сигнализировала бы условие соответственно. Если бы поток уже ожидал, то он был бы разбужен после чего, он вытянул бы событие от очереди и обработал бы его. Если бы два события вошли очереди в примерно то же время, то очередь сигнализировала бы условие дважды для пробуждения двух потоков.

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

Выполните селекторные подпрограммы

Приложения какао имеют удобный способ передать сообщения синхронизируемым способом к единственному потоку. NSObject класс объявляет методы для выполнения селектора на одном из активных потоков приложения. Эти методы позволяют Вашим потокам передать сообщения асинхронно с гарантией, что они будут выполняться синхронно целевым потоком. Например, Вы могли бы использовать, выполняют селекторные сообщения для поставки результатов распределенного вычисления основному потоку приложения или определяемому потоку координатора. Каждый запрос для выполнения селектора ставится в очередь на цикле выполнения целевого потока, и запросы тогда обрабатываются последовательно в порядке, в котором они были получены.

Для сводки выполняют селекторные подпрограммы и больше информации о том, как использовать их, посмотрите, что Какао Выполняет Селекторные Источники.

Избегите синхронизации в целом

Для любых новых проектов Вы продолжаете работать, и даже для существующих проектов, разрабатывая Ваш код и структуры данных, чтобы избежать, чтобы потребность в синхронизации была самым лучшим решением. Несмотря на то, что блокировки и другие инструменты синхронизации полезны, они действительно влияют на производительность любого приложения. И если общий замысел вызывает высокую конкуренцию среди определенных ресурсов, Ваши потоки могли бы ожидать еще дольше.

Лучший способ реализовать параллелизм состоит в том, чтобы сократить взаимодействия и взаимозависимости между Вашими параллельными задачами. Если каждая задача воздействует на ее собственный частный набор данных, она не должна защищать те данные с помощью блокировок. Даже в ситуациях, где две задачи действительно совместно используют, общие данные устанавливают, можно смотреть на способы разделить тот набор или предоставить каждой задаче ее собственную копию. Конечно, копирование наборов данных имеет свои затраты также, таким образом, необходимо взвесить те затраты против затрат синхронизации прежде, чем принять решение.

Поймите пределы синхронизации

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

Знайте об угрозах кодировать правильность

При использовании блокировок и барьеров памяти, необходимо всегда тщательно обдумывать их размещение в коде. Даже блокировки, кажущиеся хорошо помещенными, могут фактически убаюкать Вас в ложное чувство безопасности. Следующие серии примеров пытаются проиллюстрировать эту проблему путем указания на дефекты в на вид безвредном коде. Основная предпосылка - то, что у Вас есть непостоянный массив, содержащий ряд неизменных объектов. Предположим, что Вы хотите вызвать метод первого объекта в массиве. Вы могли бы сделать настолько использующий следующий код:

NSLock* arrayLock = GetArrayLock();

NSMutableArray* myArray = GetSharedArray();

id anObject;

[arrayLock lock];

anObject = [myArray objectAtIndex:0];

[arrayLock unlock];

[anObject doSomething];

Поскольку массив является непостоянным, блокировка вокруг массива препятствует тому, чтобы другие потоки изменили массив, пока Вы не получаете требуемый объект. И потому что объект, который Вы получаете, является самостоятельно неизменным, блокировка не необходима вокруг вызова к doSomething метод.

Существует проблема с предыдущим примером, все же. Что происходит, если Вы выпускаете блокировку, и другой поток входит и удаляет все объекты из массива, прежде чем Вы будете иметь возможность выполниться doSomething метод? В приложении без сборки «мусора» объект, который содержит Ваш код, мог быть выпущен, уехав anObject указывая на недопустимый адрес памяти. Для решения проблемы Вы могли бы решить просто перестроить свой существующий код и выпустить блокировку после Вашего вызова к doSomething, как показано здесь:

NSLock* arrayLock = GetArrayLock();

NSMutableArray* myArray = GetSharedArray();

id anObject;

[arrayLock lock];

anObject = [myArray objectAtIndex:0];

[anObject doSomething];

[arrayLock unlock];

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

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

NSLock* arrayLock = GetArrayLock();

NSMutableArray* myArray = GetSharedArray();

id anObject;

[arrayLock lock];

anObject = [myArray objectAtIndex:0];

[anObject retain];

[arrayLock unlock];

[anObject doSomething];

[anObject release];

Несмотря на то, что предыдущие примеры очень просты в природе, они действительно иллюстрируют очень важный тезис. Когда дело доходит до правильности необходимо думать вне очевидных проблем. Управление памятью и другие аспекты Вашего проекта могут также быть затронуты присутствием многократных потоков, таким образом, необходимо думать о тех проблемах передняя сторона. Кроме того, необходимо всегда предполагать, что компилятор сделает худшую вещь когда дело доходит до безопасности. Этот вид осведомленности и бдительности должен помочь Вам избежать потенциальных проблем и гарантировать, что Ваш код ведет себя правильно.

Для дополнительных примеров того, как сделать Вашу программу ориентированной на многопотоковое исполнение, см. Сводку Потокобезопасности.

Не упустите мертвые блокировки и динамические взаимоблокировки

Любое время поток пытается взять больше чем одну блокировку одновременно, существует потенциал для мертвой блокировки для появления. Мертвая блокировка происходит, когда два различных потока содержат блокировку, в которой нуждается другой, и затем попытайтесь получить блокировку, сохраненную другим потоком. Результат состоит в том, что каждый поток блокирует постоянно, потому что он никогда не может получать другую блокировку.

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

Лучший способ избежать и ситуаций с мертвой блокировкой и динамической взаимоблокировкой состоит в том, чтобы взять только одну блокировку за один раз. Если необходимо получить больше чем одну блокировку за один раз, необходимо удостовериться, что другие потоки не пытаются сделать что-то подобное.

Используйте энергозависимые переменные правильно

Если Вы уже используете взаимное исключение для защиты раздела кода, автоматически не предполагайте, что необходимо использовать volatile ключевое слово для защиты важных переменных в том разделе. Взаимное исключение включает барьер памяти для обеспечения надлежащего упорядочивания операций хранилища и загрузки. Добавление volatile ключевое слово к переменной в критическом разделе вынуждает значение быть загруженным из памяти каждый раз, когда к этому получают доступ. Комбинация двух методов синхронизации может быть необходимой в конкретных случаях, но также и приводит к значительной потере производительности. Если одного только взаимного исключения достаточно для защиты переменной, опустите volatile ключевое слово.

Также важно, чтобы Вы не использовали энергозависимые переменные в попытке избежать использования взаимных исключений. В целом взаимные исключения и другие механизмы синхронизации являются лучшим способом защитить целостность Ваших структур данных, чем энергозависимые переменные. volatile ключевое слово только гарантирует, что переменная загружается из памяти, а не сохранена в регистре. Это не гарантирует, что к переменной получает доступ правильно Ваш код.

Используя взаимоисключающую блокировку POSIX

Взаимоисключающие блокировки POSIX чрезвычайно просты в использовании из любого приложения. Для создания взаимоисключающей блокировки Вы объявляете и инициализируете a pthread_mutex_t структура. Чтобы заблокировать и разблокировать взаимоисключающую блокировку, Вы используете pthread_mutex_lock и pthread_mutex_unlock функции. Перечисление 4-2 показывает абсолютный код, требуемый инициализировать и использовать взаимоисключающую блокировку потока POSIX. Когда Вы будете сделаны с блокировкой, просто вызовите pthread_mutex_destroy высвобождать структуры данных блокировки.

Перечисление 4-2  Используя взаимоисключающую блокировку

pthread_mutex_t mutex;

void MyInitFunction()

{

    pthread_mutex_init(&mutex, NULL);

}

void MyLockingFunction()

{

    pthread_mutex_lock(&mutex);

    // Do work.

    pthread_mutex_unlock(&mutex);

}

Используя класс NSLock

NSLock возразите реализует основное взаимное исключение для приложений Какао. Интерфейс для всех блокировок (включая NSLock) фактически определяется NSLocking протокол, определяющий lock и unlock методы. Вы используете эти методы, чтобы получить и выпустить блокировку так же, как Вы были бы любое взаимное исключение.

В дополнение к стандартному поведению при блокировании, NSLock класс добавляет tryLock и lockBeforeDate: методы. tryLock если блокировка недоступна, метод пытается получить блокировку, но не блокирует; вместо этого, метод просто возвращается NO. lockBeforeDate: метод пытается получить блокировку, но разблокирует поток (и возвраты NO) если блокировка не получена в пределе требуемого времени.

Следующий пример показывает, как Вы могли использовать NSLock возразите для координирования обновления дисплея, данные которого вычисляются несколькими потоками. Если поток не может сразу получить блокировку, это просто продолжает свои вычисления, пока это не может получить блокировку и обновить дисплей.

BOOL moreToDo = YES;

NSLock *theLock = [[NSLock alloc] init];

...

while (moreToDo) {

    /* Do another increment of calculation */

    /* until there’s no more to do. */

    if ([theLock tryLock]) {

        /* Update display used by all threads. */

        [theLock unlock];

    }

}

Используя @synchronized директиву

@synchronized директива является удобным способом создать взаимоисключающие блокировки на лету в коде Objective C. @synchronized директива делает то, что сделала бы любая другая взаимоисключающая блокировка — это препятствует тому, чтобы различные потоки получили ту же блокировку одновременно. В этом случае, однако, Вы не должны создавать взаимное исключение или объект блокирования непосредственно. Вместо этого Вы просто используете любой объект Objective C в качестве маркера блокировки, как показано в следующем примере:

- (void)myMethod:(id)anObj

{

    @synchronized(anObj)

    {

        // Everything between the braces is protected by the @synchronized directive.

    }

}

Объект передал @synchronized директива является уникальным идентификатором, используемым для различения защищенного блока. Если Вы выполняете предыдущий метод в двух различных потоках, передавая различный объект для anObj параметр на каждом потоке, каждый взял бы его блокировку и продолжал бы обрабатывать, не будучи блокированным другим. При передаче того же объекта в обоих случаях, однако, один из потоков получил бы блокировку сначала, и другой блокирует, пока первый поток не завершил критический раздел.

В качестве меры предосторожности, @synchronized блок неявно добавляет обработчик исключений к защищенному коду. Этот обработчик автоматически выпускает взаимное исключение, если выдается исключение. Это означает это для использования @synchronized директива, необходимо также включить обработку исключений Objective C в коде. Если Вы не хотите дополнительные издержки, вызванные неявным обработчиком исключений, необходимо рассмотреть использование классов блокировки.

Для получения дополнительной информации о @synchronized директива, посмотрите Язык программирования Objective C.

Используя другие блокировки какао

Следующие разделы описывают процесс для использования нескольких других типов блокировок Какао.

NSRecursiveLock *theLock = [[NSRecursiveLock alloc] init];

void MyRecursiveFunction(int value)

{

    [theLock lock];

    if (value != 0)

    {

        --value;

        MyRecursiveFunction(value);

    }

    [theLock unlock];

}

MyRecursiveFunction(5);

id condLock = [[NSConditionLock alloc] initWithCondition:NO_DATA];

while(true)

{

    [condLock lock];

    /* Add data to the queue. */

    [condLock unlockWithCondition:HAS_DATA];

}

while (true)

{

    [condLock lockWhenCondition:HAS_DATA];

    /* Remove data from the queue. */

    [condLock unlockWithCondition:(isEmpty ? NO_DATA : HAS_DATA)];

    // Process the data locally.

}

Используя класс NSCondition

NSCondition класс обеспечивает ту же семантику как условия POSIX, но обертывает и требуемую блокировку и структуры данных условия в отдельном объекте. Результатом является объект, который можно заблокировать как взаимное исключение и затем ожидать на подобном условие.

Перечисление 4-3 показывает фрагмент кода, демонстрирующий последовательность событий для ожидания на NSCondition объект. cocoaCondition переменная содержит NSCondition возразите и timeToDoWork переменная является целым числом, сразу постепенно увеличивающимся от другого потока до сигнализации условия.

Перечисление 4-3  Используя условие Какао

[cocoaCondition lock];

while (timeToDoWork <= 0)

    [cocoaCondition wait];

timeToDoWork--;

// Do real work here.

[cocoaCondition unlock];

Перечисление 4-4 показывает, что код раньше сигнализировал условие Какао и постепенно увеличивал предикатную переменную. Необходимо всегда блокировать условие прежде, чем сигнализировать его.

Перечисление 4-4  , Сигнализирующее условие Какао

[cocoaCondition lock];

timeToDoWork++;

[cocoaCondition signal];

[cocoaCondition unlock];

Используя условия POSIX

Блокировки условия потока POSIX требуют использования и структуры данных условия и взаимного исключения. Несмотря на то, что две структуры блокировки являются отдельными, взаимоисключающая блокировка глубоко связывается к структуре условия во время выполнения. Потоки, ожидающие на сигнале, должны всегда использовать ту же взаимоисключающую блокировку и структуры условия вместе. Изменение соединения может вызвать ошибки.

Перечисление 4-5 показывает основную инициализацию и использование условия и предиката. После инициализации и условие и взаимоисключающая блокировка, поток ожидания вводит некоторое время цикл с помощью ready_to_go переменная как ее предикат. Только, когда предикат установлен, и условие, впоследствии сообщенное, приводит в порядок поток ожидания, будят и начинают выполнять его работу.

Перечисление 4-5  Используя условие POSIX

pthread_mutex_t mutex;

pthread_cond_t condition;

Boolean     ready_to_go = true;

void MyCondInitFunction()

{

    pthread_mutex_init(&mutex);

    pthread_cond_init(&condition, NULL);

}

void MyWaitOnConditionFunction()

{

    // Lock the mutex.

    pthread_mutex_lock(&mutex);

    // If the predicate is already set, then the while loop is bypassed;

    // otherwise, the thread sleeps until the predicate is set.

    while(ready_to_go == false)

    {

        pthread_cond_wait(&condition, &mutex);

    }

    // Do work. (The mutex should stay locked.)

    // Reset the predicate and release the mutex.

    ready_to_go = false;

    pthread_mutex_unlock(&mutex);

}

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

Перечисление 4-6  , Сигнализирующее блокировку условия

void SignalThreadUsingCondition()

{

    // At this point, there should be work for the other thread to do.

    pthread_mutex_lock(&mutex);

    ready_to_go = true;

    // Signal the other thread to begin work.

    pthread_cond_signal(&condition);

    pthread_mutex_unlock(&mutex);

}