С учетом ранее данных рекомендаций этот код выглядит вполне корректным. Однако вытеснение потока AddSharedElement сразу же после того, как он блокирует список А, и непосредственно перед тем, как он попытается заблокировать список В, приведет к взаимоблокировке потоков, если поток DeleteSharedElement начнет выполняться до того, как возобновится выполнение потока AddSharedElement. Каждый из потоков владеет мьютексом, который необходим другому потоку, и ни один из потоков не может перейти к вызову функции ReleaseMutex, который разблокировал бы другой поток.

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

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

Гораздо более простой метод, который описывается почти в любом учебнике по ОС, заключается в предварительном определении "иерархии мьютексов" и программировании потоков таким образом, чтобы захват ими мьютексов осуществлялся в строгом соответствии с заданным иерархическим порядком, а освобождение — в обратном порядке. Эта иерархия может устанавливаться произвольно или естественным образом определяться структурой самой задачи, но в любом случае ее должны придерживаться все потоки. В данном примере лишь требуется, чтобы функция удаления мьютекса поочередно ожидала освобождения списков А и В, и тогда взаимоблокировка потоков никогда не случится, если указанная иерархическая очередность будет соблюдаться всеми потоками в любом месте программы.

Еще одним действенным методом снижения риска взаимоблокировки является размещение двух дескрипторов мьютексов в массиве и использование функции WaitForMultipleObjects с флагом fWaitAll, значение которого установлено равным True, вследствие чего поток в результате выполнения одной атомарной операции будет захватывать либо оба мьютекса, либо ни одного. В случае использования объектов CRITICAL_SECTION описанная методика неприменима.

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

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

• Имеется возможность организовать ожидание мьютекса с использованием конечного интервала ожидания, тогда как в случае объектов CS возможен только опрос их состояния.

• Мьютексам можно присваивать имена, и их могут совместно использовать потоки, принадлежащие разным процессам.

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

• Поток, создающий мьютекс, может сразу же указать, что он становится его владельцем. В случае объектов CS за право владения объектом могут состязаться несколько потоков.

• Обычно, хотя и не всегда, использование объектов CS обеспечивает более высокую производительность по сравнению с той, которая достигается при использовании мьютексов. Этот вопрос более подробно обсуждается в главе 9.

В NT для синхронизации доступа к кучам (глава 5) предусмотрены две функции — HeapLock и HeapUnlock. В каждой из этих функций единственным аргументом является дескриптор. Эти функции удобно применять в тех случаях, когда используется флаг HEAP_NO_SERIALIZE, или когда потоку необходимы права исключительного доступа к куче.