Объектами ядра ос windows специально предназначенными для синхронизации потоков являются

Critical Sections

В составе API ОС Windows имеются специальные и эффективные функции для организации входа в критическую секцию и выхода из нее потоков одного процесса в режиме пользователя. Они называются EnterCriticalSection и LeaveCriticalSection и имеют в качестве параметра предварительно проинициализированную структуру типа CRITICAL_SECTION.

Примерная схема программы может выглядеть следующим образом.

CRITICAL_SECTION cs; 
DWORD WINAPI SecondThread() 
{ 
 InitializeCriticalSection(&cs);

EnterCriticalSection(&cs); 
… критический участок кода
LeaveCriticalSection(&cs); 
} 

main () 
{
InitializeCriticalSection(&cs);
CreateThread(NULL, 0, SecondThread,…);


EnterCriticalSection(&cs); 
… критический участок кода
LeaveCriticalSecLion(&cs); 
DeleteCriticalSection(&cs);
}

Функции EnterCriticalSection и LeaveCriticalSection реализованы на основе Interlocked-функций, выполняются атомарным образом и работают очень быстро. Существенным является то, что в случае невозможности входа в критический участок поток переходит в состояние ожидания. Впоследствии, когда такая возможность появится, поток будет «разбужен» и сможет сделать попытку входа в критическую секцию. Механизм пробуждения потока реализован с помощью объекта ядра «событие» (event), которое создается только в случае возникновения конфликтной ситуации.

Уже говорилось, что иногда, перед блокированием потока, имеет смысл некоторое время удерживать его в состоянии активного ожидания. Чтобы функция EnterCriticalSection выполняла заданное число циклов спин-блокировки, критическую секцию целесообразно проинициализировать с помощью функции InitalizeCriticalSectionAndSpinCount.

Прогон программы

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

Синхронизация потоков с использованием объектов ядра

Критические секции, рассмотренные в предыдущем разделе, подходят для синхронизации потоков одного процесса. Задачу синхронизации потоков различных процессов принято решать с помощью объектов ядра. Объекту ядра может быть присвоено имя, они позволяют задавать тайм-аут для времени ожидания и обладают еще рядом возможностей для реализации гибких сценариев синхронизации. Однако их использование связано с переходом в режим ядра (примерно 1000 тактов процессора), то есть они работают несколько медленнее, нежели критические секции.

Почти все объекты ядра, рассмотренные ранее, в том числе, процессы, потоки и файлы, пригодны для решения задач синхронизации. В контексте задач синхронизации о каждом из объектов можно сказать, находится ли он в свободном (сигнальном, signaled state) или занятом (nonsignaled state) состоянии. Правила перехода объекта из одного состояния в другое зависят от объекта. Например, если поток выполняется, то он находится в занятом состоянии, а если поток успешно завершил ожидание семафора, то семафор находится в занятом состоянии.

Потоки находятся в состоянии ожидания, пока ожидаемые ими объекты заняты. Как только объект освобождается, ОС будит поток и позволяет продолжить выполнение. Для приостановки потока и перевода его в состояние ожидания освобождения объекта используется функция

DWORD WaitForSingleObject(HANDLE hObject, DWORD dwMilliseconds);

где hObject — описатель ожидаемого объекта ядра, а второй параметр — максимальное время ожидания объекта.

Поток создает объект ядра при помощи семейства функций Create ( CreateSemaphore, CreateThread и т.д.), после чего объект посредством описателя становится доступным всем потокам данного процесса. Копия описателя может быть получена при помощи функции DuplicateHandle и передана другому процессу, после чего потоки смогут воспользоваться этим объектом для синхронизации.

Другим, более распространенным способом получения описателя является открытие существующего объекта по имени, поскольку многие объекты имеют имена в пространстве имен объектов.
Имя объекта — один из параметров Create -функций. Зная имя объекта, поток, обладающий нужными правами доступа, получает его описатель с помощью Open -функций. Напомним, что в структуре, описывающей объект, имеется счетчик ссылок на него, который увеличивается на 1 при открытии объекта и уменьшается на 1 при его закрытии.

Несколько подробнее рассмотрим те объекты ядра, которые предназначены непосредственно для решения проблем синхронизации.

Семафоры

Известно, что семафоры, предложенные Дейкстрой в 1965 г., представляет собой целую переменную в пространстве ядра, доступ к которой, после ее инициализации, может осуществляться через две атомарные операции: wait и signal (в ОС Windows это функции WaitForSingleObject и ReleaseSemaphore соответственно).

wait(S):  если S <= 0 процесс блокируется 
   (переводится в состояние ожидания);    
              в противном случае S = S - 1;                               
signal(S):  S = S + 1

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

Ниже приведен пример синхронизации программы async с помощью семафоров.

#include <windows.h>
#include <stdio.h>
#include <math.h>

int Sum = 0, iNumber=5, jNumber=300000;
HANDLE hFirstSemaphore, hSecondSemaphore;

DWORD WINAPI SecondThread(LPVOID)
{
  int i,j;
  double a,b=1.;
    for (i = 0; i < iNumber; i++)
  {
    WaitForSingleObject(hSecondSemaphore, INFINITE); 
    for (j = 0; j < jNumber; j++)
    {
      Sum = Sum + 1;  a=sin(b); 
     }
    
     ReleaseSemaphore(hFirstSemaphore, 1, NULL);
    }
  return 0;
}

void main()
{
  int i,j;
  HANDLE  hThread;
  DWORD  IDThread;
  double a,b=1.;

  hFirstSemaphore = CreateSemaphore(NULL, 0, 1, "MyFirstSemaphore");
  hSecondSemaphore = CreateSemaphore(NULL, 1, 1, "MySecondSemaphore1");
  hThread=CreateThread(NULL, 0, SecondThread, NULL, 0, &IDThread);
  if (hThread == NULL) return;    
  
  for (i = 0; i < iNumber; i++)
  {
	WaitForSingleObject(hFirstSemaphore, INFINITE);
        for (j = 0; j < jNumber; j++)
    {
      Sum = Sum - 1;  a=sin(b);
	}
    	printf(" %d ",Sum);	
	ReleaseSemaphore(hSecondSemaphore, 1, NULL);  
  }	  

WaitForSingleObject(hThread, INFINITE); // ожидание окончания потока SecondThread
CloseHandle(hFirstSemaphore);
CloseHandle(hSecondSemaphore);
printf(" %d ",Sum);	
return;
}

В данной программе синхронизация действий двух потоков , обеспечивающая одинаковый результат для всех запусков программы, выполнена с помощью двух семафоров, примерно так, как это делается в задаче producer-consumer, см., например
[
Таненбаум
]
. Потоки поочередно открывают друг другу дорогу к критическому участку. Первым начинает работать поток SecondThread, поскольку значение счетчика удерживающего его семафора проинициализировано единицей при создании этого семафора.
Синхронизацию с помощью семафоров потоков разных процессов рекомендуется выполнить в качестве самостоятельного упражнения.

Мьютексы

Мьютексы также представляют собой объекты ядра, используемые для синхронизации, но они проще семафоров, так как регулируют доступ к единственному ресурсу и, следовательно, не содержат счетчиков.
По существу они ведут себя как критические секции, но могут синхронизировать доступ потоков разных процессов. Инициализация мьютекса осуществляется функцией CreateMutex, для входа в критическую секцию используется функция WaitForSingleObject, а для выхода — ReleaseMutex.

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

События

Объекты «события» — наиболее примитивные объекты ядра. Они предназначены для информирования одного потока другим об окончании какой-либо операции. События создаются функцией CreateEvent. Простейший вариант синхронизации: переводить событие в занятое состояние функцией WaitForSingleObject и в свободное — функцией SetEvent.

В руководстве по программированию
[
Рихтер
]
,
[
Харт
]
, рассматриваются более сложные сценарии, связанные с типом события (сбрасываемые вручную и сбрасываемые автоматически) и с управлением синхронизацией групп потоков, а также ряд дополнительных полезных функций.

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

Суммарные сведения об объектах ядра

В руководствах по программированию, см., например,
[
Рихтер
]
, и в MSDN содержатся сведения и о других объектах ядра применительно к синхронизации потоков.

В частности, существуют следующие свойства объектов:

• процесс и поток находятся в занятом состоянии, когда активны, и в свободном состоянии, когда завершаются;
• файл находится в занятом состоянии, когда выдан запрос на ввод-вывод, и в свободном состоянии, когда операция ввода-вывода завершена;
• уведомление об изменении файла находится в занятом состоянии, когда в файловой системе нет изменений, и в свободном — когда изменения обнаружены;
• и т.д.

Синхронизация в ядре

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

Одна из проблем связана с тем, что код ядра зачастую работает на приоритетных IRQL (уровни IRQL рассмотрены в
«Базовые понятия ОС Windows»
) уровнях «DPC/dispatch» или «выше», известных как «высокий IRQL». Это означает, что традиционные средства синхронизации, связанные с приостановкой потока, не могут быть использованы, поскольку процедура планирования и запуска другого потока имеет более низкий приоритет.
Вместе с тем существует опасность возникновения события, чей IRQL выше, чем IRQL критического участка, который будет в этом случае вытеснен. Поэтому в подобных ситуациях прибегают к приему, который называется «запрет прерываний»
[
Карпов
]
,
[
Таненбаум
]
. В случае Windows этого добиваются, искусственно повышая IRQL критического участка до самого высокого уровня, используемого любым возможным источником прерываний. В результате критический участок может беспрепятственно выполнить свою работу.

К сожалению, для мультипроцессорных систем подобная стратегия не годится. Запрет прерываний на одном из процессоров не исключает прерываний на другом процессоре, который может продолжить свою работу и получить доступ к критическим данным. В этом случае нужен специальный протокол установки взаимоисключения. Основой этого протокола является установка блокирующей переменной (переменой-замка), сопоставленной с каждой глобальной структурой данных, с помощью TSL команды. Поскольку установка замка происходит в результате активного ожидания, то говорят, что код ядра устанавливает (захватывает) спин-блокировку. Установка спин-блокировки происходит при высоких IRQL уровнях, поэтому код ядра, захватывающего спин-блокировку и удерживающего ее для выполнения критической секции кода, никогда не вытесняется. Установка и освобождение спин-блокировок осуществляется функциями ядра KeAcquireSpinlock и KeReleaseSpinlock, которые активно используются в ядре и драйверах устройств.
На однопроцессорных системах установка и снятие спин-блокировок реализуется простым повышением и понижением IRQL.

Наконец, имея набор глобальных ресурсов, в данном случае — спин-блокировок, необходимо решить проблему возникновения потенциальных тупиков
[
Сорокина
]
. Например, поток 1 захватывает блокировку 1, а поток 2 захватывает блокировку 2. Затем поток 1 пытается захватить блокировку 2, а поток 2 — блокировку 1. В результате оба потока ядра виснут. Одним из решений данной проблемы является нумерация всех ресурсов и выделение их только в порядке возрастания номеров
[
Карпов
]
. В случае Windows имеется иерархия спин-блокировок: все они помещаются в список в порядке убывания частоты использования и должны захватываться в том порядке, в каком они указаны в списке.

В случае низких IRQL синхронизация осуществляется традиционным образом — при помощи объектов ядра.

Заключение

Проблема недетерминизма является одной из ключевых в параллельных вычислительных средах. Традиционное решение — организация взаимоисключения. Для синхронизации с применением переменной-замка используются Interlocked-функции, поддерживающие атомарность некоторой последовательности операций. Взаимоисключение потоков одного процесса легче всего организовать с помощью примитива Crytical Section. Для более сложных сценариев рекомендуется применять объекты ядра, в частности, семафоры, мьютексы и события. Рассмотрена проблема синхронизации в ядре, основным решением которой можно считать установку и освобождение спин-блокировок.

Цель работы: получение практических навыков по использованию Win32 API для синхронизации потоков

Дескрипторы и идентификаторы потоков

Тема о дескрипторах, псевдодескрипторах и идентификаторах потоков аналогична теме об аналогичных характеристиках процессов.

Функция CreateProcess возвращает идентификатор и дескриптор первого (и только первого) потока, выполняющегося во вновь созданном процессе. Функция Create Thread тоже возвращает идентификатор потока, но область действия которого — вся система.

Поток может использовать функцию GetCurrentThreadId, чтобы получить собственный ID. Функция GetWindowThreadProcessId возвращает идентификатор того потока, который создал конкретное окно (как идентификатор процесса, которому принадлежит данный поток).

Согласно документации Win32, Win32 API не предлагает способа для получения дескриптора потока по его идентификатору. Если бы дескрипторы можно было находить таким образом, то процесс, которому принадлежат потоки, завершался бы неудачей, так как другой процесс смог бы выполнять несанкционированные операции с его потоками, например, приостанавливать поток, возобновлять его действие, изменять приоритет или завершать его работу. Запрашивать дескриптор следует у процесса, создавшего данный поток, или у самого потока.

Наконец, поток может вызывать функцию GetCurrentThread для получения собственного псевдодескриптора. Как и в случае псевдодескрипторов процессов, псевдодескриптор потока может использоваться только для вызова процесса и не может наследоваться. Можно использовать функцию Duplicate Handle для получения настоящего дескриптора потока по его псевдодескриптору так же, как это делается в процессах.

Приоритет потоков

Термин многозадачность (multitasking) или мультипрограммирование (multiprogramming), обозначает возможность управлять несколькими процессами (или несколькими потоками) на базе одного процессора. Многопроцессорной обработкой (multiprocessing) называется управление некоторым числом процессов или потоков на нескольких процессорах.

Компьютер может одновременно выполнять команды двух разных процессов только в многопроцессорной среде. Однако даже на одном процессоре с помощью переключения задач (task switching) можно создать впечатление, что одновременно выполняются команды нескольких процессов.

В старой 16-разрядной Windows существовал только один поток. Более того, в данной системе был реализован метод кооперативной (cooperative) многозадачности, который состоит в том, что каждое приложение само отвечает за высвобождение единственного системного потока, после чего могут выполняться другие приложения. Если программа выполняла задачи, требующие значительного времени, такие как форматирование гибкого диска, все другие загруженные приложения должны были ждать. А если программа, написанная с ошибками, входила в бесконечный цикл, то вся система становилась непригодной для использования («зависала»), требовала перезагрузки с выключением питания.

Уровни приоритета потоков

Win32 значительно отличается от Win16. Во-первых, она является многопоточной (multithreaded), что определяет ее многозадачность. Во-вторых, в ней реализована модель вытесняющей (preemptive) многозадачности, в которой операционная система решает, когда каждый поток получает процессорное время, выделяемое квантами времени (time slices), и сколько именно времени выделяется. Временной интервал в Windows называется квантом.

Продолжительность кванта времени зависит от аппаратуры и может фактически меняться от потока к потоку. Например, базовое значение в Windows 95 со составляет 20 мс, для Windows NT Workstation (на базе процессора Pentium) -30 мс, для Windows NT Server — 180 мс.

Давайте выясним, каким образом Windows выделяет кванты времени потокам в системе. Эти процедуры в Windows 9x и Windows NT довольно похожи, но не идентичны.

Каждый поток в системе имеет Уровень приоритета (priority level), который представляет собой число в диапазоне от 0 до 31. Ниже перечислено то самое основное, что нужно знать:

· если существуют какие-либо потоки с приоритетом 31, которые требуют процессорного времени, то есть не находятся в состоянии ожидания (not idle), операционная система перебирает эти потоки (независимо от того, каким процессам они принадлежат), выделяя по очереди каждому из них кванты времени. Потокам с более низким приоритетом кванты времени совсем не выделяются, поэтому они не выполняются. Если нет активных потоков с приоритетом 31, операционная система ищет активные потоки с уровнем приоритета 30 и т. д. Однако потоки довольно часто простаивают. Тот факт, что приложение загружено, не означает, что все его потоки активны. Поэтому у потоков с более низким приоритетом все же есть возможность работать. Более того, если пользователь нажимает клавишу, относящуюся к процессу, потоки которого простаивают, операционная система временно выделяет процессорное время соответствующему потоку, чтобы он мог обработать нажатие клавиши;

· приоритет 0 зарезервирован исключительно за специальным системным потоком, который называется потоком нулевой страницы (zero page thread). Он освобождает незадействованные области памяти. Существует также поток idle, который работает с уровнем приоритета 0, опрашивая систему в поисках какой-нибудь работы;

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

· для того чтобы перейти с одного потока на другой, система осуществляет переключение контекста (context switch). Это процедура, сохраняющая состояние процессора (регистров и стека) и загрузки соответствующих значений другого потока.

Назначение приоритета потоку

Назначение потоку приоритета происходит в два этапа. Во-первых, каждому процессу в момент создания присваивается класс приоритета. Узнать класс приоритета можно с помощью функции GetPriorityClass, а изменить — с помощью функции SetPriorityClass. Ниже приведены имена классов приоритета процессов, уровни приоритета и константы, которые используются с этими вышеупомянутыми функциями (как и с функцией CreateProcess).

Большинство процессов должно получать класс уровня приоритета Normal (обычный). Однако некоторым приложениям, таким как приложения мониторинга системы, возможно, более уместно назначать приоритет Idle (ожидания). Назначения приоритета Realtime (реального времени) обычно следует избегать, потому что в этом случае потоки изначально получают приоритет более высокий, чем системные потоки, такие как потоки ввода от клавиатуры и мыши, очистки кэша и обработки нажатия клавиш Ctrl+Alt+Del. Такой приоритет может быть подходящим для краткосрочных, критичных к времени выполнения процессов, которые относятся к взаимодействию с аппаратурой.

При создании уровень приоритета потока по умолчанию устанавливается равным уровню класса приоритета процесса, создавшего данный поток. Тем не менее, можно использовать функцию SetThreadPriority, чтобы изменить приоритет потока:

BOOL SetThreadPriority (

НANDLЕ hThread, // Дескриптор потока

Int NPriority // Уровень приоритета потока

);

Параметр nPriority используется для изменения приоритета потока относительно приоритета процесса, которому принадлежит данный поток. Возможные значения параметра nPriority и эффект их воздействия на уровень приоритета потока приведены ниже:

_______________________________________________________________________

Константа Уровень приоритета потоков

_______________________________________________________________________

Thread_priority_normal Уровень приоритета класса

Thread_priority_above_normal Уровень приоритета класса + 1

THREAD_PRIORITY_BELOW_N0RMAL Уровень приоритета класса — 1

Thread_priority_highest Уровень приоритета класса + 2

THREAD_PRIORITY_LOWEST Уровень приоритета класса — 2

Thread_Priority_Idle Устанавливает уровень приоритета 1 для всех классов приоритета процессов за исключением Realtime. В этом случае устанавливает уровень приоритета 16.

Thread_priority_time_critical Устанавливает уровень приоритета 15 для всех классов приоритета процессов за исключением Realtime. В этом случае устанавливает уровень приоритета 31.

____________________________________________________________________

Повышение приоритета потока и квант изменений приоритета

Диапазон приоритета от 1 до 15 известен как диапазон динамического приоритета (Dynamic Priority), а диапазон от 16 до 31 — как диапазон приоритета реального времени (Realtime Priority).

В Windows NT приоритет потока, находящийся в динамическом диапазоне, может временно повышаться операционной системой в различные моменты времени Соответственно, нижний уровень приоритета потока (установленный программистом с помощью API функции) называется уровнем его базового приоритетa (Base Priority) API функция Windows NT SetProcessPriorityBoost может использоваться для разрешения или запрещения временных изменений приоритета (priority boosting). Правда, она не поддерживается в Windows 9х.

Бывают также случаи, когда кванты времени, выделяемые потоку, временно увеличиваются.

Стремясь плавно выполнять операции, Windows будет повышать приоритет потока или увеличивать продолжительность его кванта времени при следующих условиях:

если поток принадлежит приоритетному процессу (Foreground Process), то есть процессу, окно которого активно и имеет фокус ввода; если поток первым вошел в состояние ожидания; если поток выходит из состояния ожидания; если поток совсем не получает процессорного времени.

Состояния потоков

Потоки могут находиться в одном из нескольких состояний:

Ready (готов) – находящийся в пуле (pool) потоков, ожидающих выполнения; Running (выполнение) — выполняющийся на процессоре; Waiting (ожидание), также называется idle или suspended, приостановленный — в состоянии ожидания, которое завершается тем, что поток начинает выполняться (состояние Running) или переходит в состояние Ready; Terminated (завершение) — завершено выполнение всех команд потока. Впоследствии его можно удалить. Если поток не удален, система может вновь установить его в исходное состояние для последующего использования.

Синхронизация потоков

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

Синхронизация потоков (Thread Synchronization) — это обобщенный термин, относящийся к процессу взаимодействия и взаимосвязи потоков. Учтите, что синхронизация потоков требует привлечения в качестве посредника самой операционной системы. Потоки не могут взаимодействовать друг с другом без ее участия.

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

Критические секции

Один из методов синхронизации потоков состоит в использовании критических секций (critical sections). Это единственный метод синхронизации потоков, который не требует привлечения ядра Windows. (Критическая секция не является объектом ядра). Однако этот метод может использоваться только для синхронизации потоков одного процесса.

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

До использования критической секции необходимо инициализировать ее с помощью процедуры Win32 API InitializeCriticalSection(), которая определяется (в Delphi) следующим образом:

Procedure InitializeCriticalSection(var IpCriticalSection: TRTLCriticalSection); stdcall;

Параметр IpCriticalSection представляет собой запись типа TRTLCriticalSection, которая передается по ссылке. Точное определение записи TRTLCriticalSection не имеет большого значения, поскольку вам вряд ли понадобится когда-либо заглядывать в ее содержимое. От вас требуется лишь передать неинициализированную запись в параметр IpCtitical Section, и эта запись будет тут же заполнена процедурой.

После заполнения записи в программе можно создать критическую секцию, поместив некоторый участок ее текста между вызовами функций EnterCriticalSection() и LeaveCriticalSection(). Эти процедуры определяются следующим образом:

Procedure EnterCriticalSection(var IpCriticalSection: TRTLCriticalSection); stdcall;

Procedure LeaveCriticalSection(var IpCriticalSection: TRTLCriticalSection); stdcall;

Параметр IpCriticalSection, который передается этим процедурам, является не чем иным, как записью, созданной процедурой InitializeCriticalSection().

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

Когда функция LeaveCriticalSection вызывается потоком, который владеет в текущий момент разрешением на выполнение своей критической секции кода, связанной с данным объектом «критическая секция», система может проверить, нет ли в очереди другого потока, ожидающего освобождения этого объекта. Затем система может вынести ждущий поток из состояния ожидания, и он продолжит свою работу (в выделенные ему кванты времени).

По окончании работы с записью TRTLCriticalSection необходимо освободить ее, вызвав процедуру DeleteCriticalSection(), которая определяется следующим образом:

Procedure DeleteCriticalSection(var IpCriticalSection: TRTLCriticalSection); stdcall;

Синхронизация с использованием объектов ядра

Многие объекты ядра, включая процесс, поток, файл, мьютекс, семафор, уведомление об изменении файла и событие, могут находиться в одном из двух состояний — «свободно» (Signaled) и «занято» (Nonsignaled). Вероятно, проще представлять себе эти объекты подключенными к лампочке, как на приведенном рисунке. Если свет горит, объект свободен, в обратном случае объект занят.

Например, в момент создания процесса его объект ядра находится в состоянии «занято». Когда процесс завершается, объект переходит в состояние «свободно». Аналогично выполняющиеся потоки (то есть их объекты) пребывают в состоянии «занято», но переходят в состояние «свободно», когда завершают работу. На самом деле некоторые объекты, такие как мыютекс, семафор, событие, уведомление об изменении файла, таймер ожидания, существуют исключительно для того, чтобы вырабатывать сигналы «свободно» и «занято».

Смысл всей этой «сигнализации» в том, чтобы поток мог приостанавливать свою работу до того момента, когда заданный объект перейдет в состояние «свободно». Например, поток одного процесса может временно прекратить работу до завершения другого, просто подождав, когда объект ядра этого другого процесса перейдет в состояние «свободно».

Посредством вызова функций WaitForSingleObject и WaitForMultipleObjects поток приостанавливает свое выполнение до того момента, когда заданный объект (или объекты) перейдет в состояние «свободно». Рассмотрим функции WaitForSingleObject, декларация которой выглядит так:

DWORD WaitForSingleObject(

HANDLE HHandle, // Дескриптор объекта ожидания

DWORD DwMilliseconds // Время ожидания в миллисекундах

);

Параметр HHandle является дескриптором объекта, уведомление о свободном состоянии которого требуется получить, a DwMilliseconds — это время, которое вызывающий поток готов ждать. Если DwMilliseconds равно нулю, функция немедленно вернет текущий статус заданного объекта. Таким образом, можно протестировать состояние объекта. Параметру можно также присваивать значение символьной константы INFINITE (= -1), в этом случае вызывающий поток будет ждать неограниченное время.

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

· Wait_object_0 — объект находится в состоянии «свободно»;

· WAIT_TIMEOUT — интервал ожидания, заданный DwMilliseconds, истек,

А нужный объект по прежнему находится в состоянии «занято»;

· WAIT_ABANDONED относится только к мьютексу и означает, что объект не

был освобожден потоком, который владел им до своего завершения;

· WAIT_FAILED — при выполнении функции произошла ошибка.

Объекты «мьютекс»

Мьютекс (MUTual Exclusions— взаимоисключения) — это объект ядра, который можно использовать для синхронизации потоков из разных процессов. Он может принадлежать или не принадлежать некоторому потоку. Если мьютекс принадлежит потоку, то он находится в состоянии «занято». Если данный объект не относится ни к одному потоку, то он находится в состоянии «свободно». Другими словами, принадлежать для него означает быть в состоянии «занято».

Если мьютекс не принадлежит ни одному потоку, первый поток, который вызовет функцию WaitForSingleObject, завладевает данным объектом, и тот переходит в состояние «занято». В определенном смысле мьютекс похож на выключатель, которым может пользоваться любой поток по принципу «первым пришел — первым обслужили» (first-come-first,-served).

Дело в том, что при попытке с помощью вызова функции WaitForSingleObject завладеть мьютексом, который уже находится в состоянии «занято», поток переводится в состояние ожидания до того момента, когда данный объект освободится, то есть когда «владелец» мьютекса его освободит (переведет в состояние «свободно»).

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

Мьютексы создаются с помощью вызова функции CreateMutex:

HANDLE CreateMutexi

LPSECURITY_ATTRIBUTES IpMutexAttributes,

// Указатель на атрибуты защиты.

BOOL BInitialOwner, // флаг первоначального владельца.

LPCTSTR IpName // Указатель на имя мьютекса.

);

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

Параметр blnitialOwner определяет, следует ли считать поток, создающий мьютекс, его владельцем. Если этот параметр равен False, значит, мьютекс не имеет владельца.

Параметр IpName представляет имя мыотскса. Если вы не собираетесь присваивать мьютексу имя, установите этот параметр равным nil. Если же значение этого параметра отлично от nil, функция выполнит в системе поиск мьютекса с таким же именем. При успешном завершении поиска функция вернет дескриптор найденного мьютекса, в противном случае возвращается дескриптор нового мьютекса. При наличии имени этот объект может совместно использоваться несколькими процессами. Если каким-то процессом создается мьютекс с именем, то поток другого процесса может вызывать функции CreateMutex или OpenMutex с тем же самым именем. В любом случае система просто передаст вызывающему потоку дескриптор исходного мьютекса. Другой способ совместно использовать мьютекс — вызвать функцию DuplicateHandle.

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

BOOL ReleaseMutex(

HANDLE HMutex // Дескриптор мьютекса.

);

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

По завершении использования мьютекса необходимо закрыть его с помощью функции Win32 API CloseHandle().

События

События используются в качестве сигналов о завершении какой-либо операции. Однако в отличие от мьютексов, они не принадлежат ни одному потоку. Например, поток А создает событие с помощью функции CreateEvent и устанавливает объект в состояние «занято». Поток В получает дескриптор этого объекта, вызвав функцию OpenEvent, затем вызывает функцию WaitForSingleObject, чтобы приостановить работу до того момента, когда поток А завершит конкретную задачу и освободит указанный объект. Когда это произойдет, система выведет из состояния ожидания поток В, который теперь владеет информацией, что поток А завершил выполнение своей задачи.

Объявление функции CreateEvent записывается таким образом:

HANDLE CreateEvent(

LPSECURITY_ATTRIBUTES IpEventAttributes,

// Указатель на атрибуты защиты.

BOOL BManualReset, // Флаг интерактивного события.

BOOL BInitialState, // Флаг первоначального состояния.

LPCTSTR IpName // Указатель на имя события.

);

Эта функция возвращает дескриптор создаваемого объекта «событие». Первый параметр определяет, наследуется ли дескриптор порожденными процессами. Если IpEventAttributes имеет значение NULL, дескриптор наследоваться не может.

Если параметр BMaNuAlReseT имеет значение TRUE, то при освобождении объект остается в этом состоянии (в отличие от объекта «мъютекс»). Это значит, что все потоки, ожидающие перехода данного объекта в состояние «свободно», будут выведены системой из состояния ожидания. Такой объект называется событием с ручным сбросом (Manual-reset event), поскольку «разбуженный» (выведенный из состояния ожидания) поток может самостоятельно сбросить состояние объекта «событие» в «занято». Если параметр bManualReset имеет значение FALSE, то система автоматически сбрасывает состояние рассматриваемого объема в «занято» после «пробуждения» первого потока, ожидающего освобождения данного объекта. Только один поток выводится из состояния ожидания, как и в случае с мьютексами. Такое событие называют событием с автоматическим сбросом (Auto-REset event).

Параметр BINitialSTate определяет первоначальное состояние (если TRUE, то «свободно», если FALSE, то «занято») данного события. Параметру IpName может быть присвоено имя события. Имя предоставляет способ совместного использования, например посредством функции OpenEvent.

В качестве дополнительного варианта, если вы не хотите иметь дела с вопросами защиты, можно установить IpEventAttributes в NULL (0&). В таком случае декларация примет следующий вид:

Declare Function CreateEvent Lib «Kernel32″ Alias «CreateEventA» ( _

ByVal IpEventAttributes As Long, _

By Val bManualReset As Long, _

By Val blmtialState As Long, _

By Val IpName As String _

) As Long

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

Объявление функции OpenEvent выглядит так:

HANDLE OpenEvent(

DWORD dwDesiredAccess, // Флаг доступа.

BOOL BlnheritHandle, // Флаг наследования.

LPCTSTR IpName // Указатель на имя события.

);

Где параметр DwDesiredAccess может принимать одно из трех значений:

· EVENT_ALL_ACCESS предоставляет полный доступ к событию;

· EVENT_MODIFY_STATE разрешает использование дескриптора события в функциях SetEvent и ResetEvent, так что вызывающий процесс может изменить состояние данного события (но ничего больше). Это важно для событий со сбросом вручную;

· SYNCHRONIZE Разрешает использование дескриптора события в любых функциях ожидания (таких как WaitForSingleObject), ждущих освобождения данного объекта.

Каждая из этих функций принимает дескриптор события в качестве аргумента. Функция SetEvent устанавливает состояние данного события в «свободно», a Reset Event «сбрасывает» событие, то есть присваивает событию статус «занято», функция PulseEvent вызывает SetEvent для освобождения ожидающих потоков, а затем вызывает ResetEvent для перевода данного события в состояние «занято».

Семафоры

Существует еще один метод синхронизации потоков, в котором используются семафорные объекты API. В семафорах применен принцип действия мьютексов, но с добавлением одной существенной детали. В них заложена возможность подсчета ресурсов, что позволяет заранее определенному числу потоков одновременно войти в синхронизуемый участок кода. Для создания семафора используется функция CreateSemaphore(), которая объявляется следующим образом:

Function CreateSemaphoreflpSemaphoreAttributes: PSecurityAttributes; llnitialCoimt, iMaximumCount: Longint; IpName: PChar): THandle; stdcall;

Как и в случае функции CreateMutex(), первым параметром, передаваемым функции CreateSemaphore(), является указатель на запись TSecurityAttributes, причем значение Nil соответствует согласию на использование стандартных атрибутов защиты.

Параметр llnitialCount представляет собой начальное значение счетчика семафорного объекта. Это число может находиться в диапазоне от 0 до значения IMaximumCount. Семафор доступен, если значение этого параметра больше нуля. Когда поток вызывает функцию WaitForSingleObject() или любую другую, ей подобную, значение счетчика семафора уменьшается на единицу. И наоборот, при вызове потоком функции ReleaseSemaphore() значение счетчика семафора увеличивается на единицу.

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

Параметр IpName содержит имя семафора. Поведение этого параметра аналогично поведению одноименного параметра функции CreateMutex().

Функция ReleaseSemaphore () используемая для увеличения значения счетчика семафора имеет больше параметров, чем ее «коллега» ReleaseMutex(). Объявление функции ReleaseSemaphore() выглядит следующим образом:

Function ReleaseSemaphore(hSemaphore: THandle; IReleaseCount: Longint; IpPreviousCount: Pointer): BOOL; stdcall;

С помощью параметра IReleaseCount можно задать число, на которое будет уменьшено значение счетчика семафора. При этом старое значение счетчика будет сохранено в переменной типа Longint, на которую указывает параметр IpPreviousCount, если его значение не равно Nil, Скрытый смысл этого средства состоит в том, что семафор никогда не принадлежит ни одному

Отдельному потоку. Предположим, что максимальное значение счетчика семафора было равно 10, и десять потоков вызвали функцию WaitForSingleObject(). В результате счетчик потоков сбрасывается до нуля и тем самым семафор переводится в недоступное состояние. После этого достаточно одному из потоков вызвать функцию ReleaseSemaphore() и в качестве параметра lReleaseCount передать число 10, как семафор не просто будет снова пропускать потоки, т. е. станет доступным, но и увеличит значение своего счетчика до прежнего числа — до 10. Это мощное средство может привести к возникновению в вашем приложении трудно отслеживаемых ошибок, поэтому следует использовать его с большой осторожностью.

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

Для освобождения дескриптора семафора, выделенного ему с помощью функции CreateSemaphore(), не забудьте вызвать функцию CloseHandle().

Ждущие таймеры

Ждущий таймер (waitable timer) представляет собой новый тип объектов синхронизации, поддерживаемый в Windows NT версии 4.0 и выше. Это полноценный объект синхронизации, который может использоваться для организации задержки в одном или нескольких приложениях.

Ждущий таймер работает в трех режимах. В режиме «ручного сброса» таймер переходит в установленное состояние при истечении заданной задержки и остается установленным до тех пор, пока функция SetWaitableTimer не задаст новую задержку. В режиме «автоматического сброса» таймер переходит в установленное состояние при истечении заданной задержки и остается установленным до первого успешного вызова функции ожидания. В этом режиме он напоминает объект Event в режиме автоматического сброса, поскольку каждый раз при истечении времени задержки разрешается выполнение лишь одной нити. Наконец, ждущий таймер может выполнять функции интервального таймера, который перезапускается с заданной задержкой после каждого срабатывания объекта.

Главная особенность, отличающая ждущие таймеры от системных, — то, что ждущие таймеры могут совместно использоваться несколькими приложениями. Например, вы можете приостановить несколько приложений в фоновом режиме так, чтобы они «просыпались» каждые несколько часов для выполнения некоторой операции.

Процессы получают дескрипторы ждущих таймеров так же, как они получают дескрипторы мьютексов: дублированием, наследованием или открытием по имени.

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

СОДЕРЖАНИЕ ОТЧЕТА

11. Наименование лабораторной работы, ее цель.

12. Исследование на конкретном примере следующих методов синхронизации потоков:

1. критические секции

2. мьтексы

3. события

Задачу для синхронизации выбрать на свое усмотрение.

13. Примеры разработанных приложений (описание программ, результаты и тексты программ).

Примечание:

Задачи для каждого метода синхронизации должны быть различными. Задачи должны наглядно демонстрировать выбранный метод синхронизации и учитывать его особенности. Студент, сдающий работу должен АРГУМЕНТИРОВАННО обосновать задачу, выбранную для синхронизации и метод синхронизации.

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

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

—         первый поток прочитал значение глобальной переменной в локальную;

—         ОС прерывает его, так как закончился выделенный ему квант времени процессора, и передаёт управление второму потоку;

—         второй поток также считал значение глобальной переменной в локальную, декрементировал её и записал новое значение обратно;

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

Очевидно, что изменения, внесённые вторым потоком, будут утеряны.

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

Средства синхронизации в ОС Windows:

1) критическая секция (Critical Section) – это объект, который принадлежи процессу, а не ядру. А значит, не может синхронизировать потоки из разных процессов.

Существует так же функции инициализации (создания) и удаления, вхождения и выхода из критической секции:

создание – InitializeCriticalSection(…),    удаление – DeleteCriticalSection(…),

вход – EnterCriticalSection(…),                выход – LeaveCriticalSection(…).

Ограничения: поскольку это не объект ядра, то он не виден другим процессам, то есть можно защищать только потоки своего процесса.

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

Среди синхронизирующих объектов критические разделы наиболее просты.

2) mutex – mutable exclude. Это объект ядра, у него есть имя, а значит с их помощью можно синхронизировать доступ к общим данным со стороны нескольких процессов, точнее, со стороны потоков разных процессов. Ни один другой поток не может завладеть мьютексом, который уже принадлежит одному из по­токов. Если мьютекс защищает какие-то совместно используемые данные, он сможет выполнить свою функцию только в случае, если перед обращением к этим данным каждый из потоков будет проверять состояние этого мьютекса. Windows расценивает мьютекс как объект общего доступа, который можно пере­вести в сигнальное состояние или сбросить. Сигнальное состояние мьютекса говорит о том, что он занят. Потоки должны самостоятельно ана­лизировать текущее состояние мьютексов. Если требуется, чтобы к мьютексу могли обратиться потоки других процессов, ему надо присвоить имя.

Функции:

CreateMutex(имя) – создание,                  hnd=OpenMutex(имя) – открытие,

WaitForSingleObject(hnd) – ожидание и занятие,

ReleaseMutex(hnd) – освобождение,        CloseHandle(hnd) – закрытие.

Его можно использовать в защите от повторного запуска программ.

3) семафор – semaphore. Объект ядра “семафор” используются для учёта ресурсов и служат для ограничения одновременного доступа к ресурсу нескольких потоков. Используя семафор, можно организовать работу программы таким образом, что к ресурсу одновременно смо­гут получить доступ несколько потоков, однако количество этих потоков будет ограничено. Создавая семафор, указывается максимальное количество пото­ков, которые одновременно смогут работать с ресурсом. Каждый раз, когда программа обращается к семафору, значение счетчика ресурсов семафора уменьша­ется на единицу. Когда значение счетчика ресурсов становится равным нулю, семафор недоступен.

создание CreateSemaphore,                      открытие OpenSemaphore,

занять WaitForSingleObject,                     освобождение ReleaseSemaphore

4) событие – event. События обычно просто оповещают об окончании какой-либо операции, они также являются объектами ядра. Можно не просто явным образом освободить, но так же есть операция установки события. События могут быть мануальными (manual) и единичными (single).

Единичное событие (single event) – это скорее общий флаг. Событие находится в сигнальном состоянии, если его установил какой-нибудь поток. Если для работы программы требуется, чтобы в случае возникновения события на него реа­гировал только один из потоков, в то время как все остальные потоки продолжали ждать, то используют единичное событие.

Мануальное событие (manual event) — это не про­сто общий флаг для нескольких потоков. Оно выполняет несколько более сложные функции. Любой поток может установить это событие или сбросить (очистить) его. Если событие установлено, оно останется в этом состоянии сколь угодно долгое время, вне зависимости от того, сколько потоков ожидают установки этого события. Когда все потоки, ожидающие этого события, получат сообщение о том, что событие произошло, оно автоматически сбросится.

Функции: SetEvent, ClearEvent, WaitForEvent.

Типы событий:

1) событие с автоматическим сбросом: WaitForSingleEvent.

2) событие с ручным сбросом (manual), тогда событие необходимо сбрасывать: ReleaseEvent.

Некоторые теоретики выделяют ещё один объект синхронизации:

WaitAbleTimer – объект ядра ОС, который самостоятельно переходит в свободное состояние через заданный интервал времени (будильник).