Чтение онлайн

на главную

Жанры

Системное программирование в среде Windows

Харт Джонсон М.

Шрифт:

• Если поток завершает выполнение или его выполнение прерывается до того, как он покинет (разблокирует) объект CS, то этот объект остается блокированным. Чрезвычайно полезным свойством мьютексов является то, что владеющий ими поток может завершить выполнение, не уступив прав владения мьютексом.

• Не пытайтесь получить доступ к ресурсам, защищаемым мьютексом, если функция WaitForSingleObject вызвана с использованием конечного интервала ожидания.

• Ожидать перехода блокированного мьютекса в сигнальное состояние могут сразу несколько потоков. Когда мьютекс освобождается, то только один из ожидающих потоков получает права владения мьютексом и переводится в состояние готовности планировщиком ОС на основании действующей стратегии приоритетов и планирования. Не следует делать никаких предположений относительно того, что

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

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

• Определяемая мьютексами степень детализации программы, или гранулярность мьютексов (mutex granularity), оказывает влияние на производительность и требует серьезного рассмотрения. Размер каждого критического участка кода ни в коем случае не должен превышать необходимой величины, и мьютекс не должен захватываться на более длительный промежуток времени, чем это необходимо. Использование критических участков кода чрезмерно большого размера, захватываемых на длительные промежутки времени, снижает параллелизм и может оказывать отрицательное влияние на производительность.

• Связывайте мьютекс непосредственно с ресурсом, защиту которого он должен обеспечивать, возможно, с использованием структуры данных. (Именно эта методика задействована в программах 8.1 и 8.2.)

• Максимально точно документируйте инвариант, используя для этого словесные описания либо логические, или булевские, выражения. Инвариант— это свойство защищаемого ресурса, сохранение которого неизменным вне критического участка кода вы гарантируете. Форма выражения инвариантов может быть самой различной: "элемент принадлежит обоим спискам или не принадлежит ни одному из них", "контрольная сумма данных в буфере является достоверной", "связанный список является действительным" или "0 <= nLost + nCons <= sequence". Точно сформулированные инварианты могут использоваться совместно с макросом ASSERT при отладке программ, хотя оператор ASSERT должен иметь собственный критический участок кода.

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

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

Другие функции взаимоблокировки

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

Функции взаимоблокировки настолько же полезны, насколько и эффективны; эти функции реализуются в пользовательском пространстве с применением всего

лишь нескольких машинных команд.

Функция InterlockedExchange сохраняет значение одной переменной в другой. 

LONG InterlockedExchange(LPLONG Target, LONG Value)
 

Эта функция возвращает текущее значение переменной, на которую указывает параметр Target, и устанавливает значение этой переменной равным Value. Функция InterlockedExchangeAdd прибавляет второе значение к первому. 

LONG InterlockedExchangeAdd(PLONG Addend, LONG Increment)
 

Значение Increment прибавляется к значению переменной, на которую указывает параметр Addend, а начальное значение этой переменной возвращается функцией. Данная функция позволяет увеличивать значение переменной на 2 (и более) атомарным образом, чего невозможно добиться последовательными вызовами функции InterlockedIncrement.

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

PVOID InterlockedCompareExchange(PVOID *Destination, PVOID Exchange, PVOID Comparand)
 

Эта функция выполняет атомарным образом следующие действия (использование типа данных PVOID для двух последних параметров может казаться вам непонятным):

Temp = *Destination;

if (*Destination == Comparand) *Destination = Exchange;

return Temp;

Одним из вариантов применения этой функции является управление блокировкой с целью реализации критического участка кода. *Destination является переменной блокировки (lock variable), причем значению 1 соответствует разблокированное состояние, а значению 0 — блокированное. Значение Exchange задается равным 0, a Comparand — 1. Вызывающему потоку известно, что она владеет критическим участком, если функция возвращает 1. В противном случае вызывающий поток должен "уснуть", или выполнить ожидание в состоянии занятости ("spin"), то есть совершать в течение короткого промежутка времени цикл, в котором ничего не делается, с той только целью, чтобы выждать некоторое время, а затем вновь повторить попытку. По существу, именно такой цикл и выполняет функция EnterCriticalSection, ожидая перехода в сигнальное состояние объекта CRITICAL_SECTION с ненулевым значением спин-счетчика; для получения более подробной информации по этому вопросу обратитесь к главе 9.

Учет факторов производительности при организации управленияпамятью

Программа 9.1, приведенная в следующей главе, позволяет исследовать различные аспекты производительности в условиях, когда несколько потоков соревнуются между собой за право обладания разделяемыми ресурсами. Аналогичные эффекты будут наблюдаться и в случае, когда потоки привлекаются для управления памятью с использованием функций malloc и free из многопоточной стандартной библиотеки С, поскольку эти функции используют объекты CRITICAL_SECTION для синхронизации доступа к структуре данных кучи (вы можете в этом сами убедиться, просмотрев исходный код библиотеки С). Ниже описаны два возможных способа улучшения производительности.

• Каждый поток, управляющий памятью, может создать дескриптор типа HANDLE для собственной кучи с помощью функции HeapCreate (глава 5). После этого для распределения памяти вместо функций malloc и free можно использовать функции HeapAlloc и HeapFree.

• Значение переменной окружения времени выполнения __MSVCRT_HEAP_SELECT можно установить равным __GLOBAL_HEAP_SELECTED. Это приведет к тому, что функции malloc и free будут использовать для управления памятью схему Windows, которая использует спин-блокировки (spin locks) вместо объектов CS и может быть намного более эффективной. Этот метод был предложен Гербертом Орашем (Gerbert Orasche) в статье "Configuring VC++ Multithreaded Memory Management", опубликованной в майском выпуске журнала Windows Developer's Journal за 2000 год, а представленные в этой статье результаты убедительно свидетельствуют о преимуществах данного метода в отношении производительности.

Поделиться:
Популярные книги

Восход. Солнцев. Книга X

Скабер Артемий
10. Голос Бога
Фантастика:
фэнтези
попаданцы
аниме
5.00
рейтинг книги
Восход. Солнцев. Книга X

Мастер 7

Чащин Валерий
7. Мастер
Фантастика:
фэнтези
боевая фантастика
попаданцы
технофэнтези
аниме
5.00
рейтинг книги
Мастер 7

Неудержимый. Книга XIV

Боярский Андрей
14. Неудержимый
Фантастика:
фэнтези
попаданцы
аниме
5.00
рейтинг книги
Неудержимый. Книга XIV

Все не случайно

Юнина Наталья
Любовные романы:
современные любовные романы
7.10
рейтинг книги
Все не случайно

Гром над Тверью

Машуков Тимур
1. Гром над миром
Фантастика:
боевая фантастика
5.89
рейтинг книги
Гром над Тверью

Идущий в тени 5

Амврелий Марк
5. Идущий в тени
Фантастика:
фэнтези
рпг
5.50
рейтинг книги
Идущий в тени 5

Кровь, золото и помидоры

Распопов Дмитрий Викторович
4. Венецианский купец
Фантастика:
альтернативная история
5.40
рейтинг книги
Кровь, золото и помидоры

Неудержимый. Книга VIII

Боярский Андрей
8. Неудержимый
Фантастика:
фэнтези
попаданцы
аниме
6.00
рейтинг книги
Неудержимый. Книга VIII

Чужое наследие

Кораблев Родион
3. Другая сторона
Фантастика:
боевая фантастика
8.47
рейтинг книги
Чужое наследие

Пистоль и шпага

Дроздов Анатолий Федорович
2. Штуцер и тесак
Фантастика:
альтернативная история
8.28
рейтинг книги
Пистоль и шпага

Мастер 4

Чащин Валерий
4. Мастер
Фантастика:
героическая фантастика
боевая фантастика
попаданцы
5.00
рейтинг книги
Мастер 4

Темный Патриарх Светлого Рода 6

Лисицин Евгений
6. Темный Патриарх Светлого Рода
Фантастика:
фэнтези
попаданцы
аниме
5.00
рейтинг книги
Темный Патриарх Светлого Рода 6

Лорд Системы 14

Токсик Саша
14. Лорд Системы
Фантастика:
фэнтези
попаданцы
рпг
5.00
рейтинг книги
Лорд Системы 14

Падение Твердыни

Распопов Дмитрий Викторович
6. Венецианский купец
Фантастика:
попаданцы
альтернативная история
5.33
рейтинг книги
Падение Твердыни