Дескриптор - лексическая единица (слово, словосочетание) информационно-поискового языка, выражающая основное смысловое содержание какого-либо текста. Используется при информационном поиске документов в информационно-поисковых системах.
Файловый дескриптор — это неотрицательное целое число. Когда мы открываем существующий файл и создаем новый файл, ядро возвращает процессу файловый дескриптор.
Дескриптор сегмента — служебная структура в памяти, которая определяет сегмент. Длина дескриптора равна восьми байтам.
Дескриптор шлюза — служебная структура данных, служащая для различных переходов. Используется только в защищённом режиме. В реальном режиме некоторым аналогом может служить дальний адрес. Длина дескриптора стандартна и равна восьми байтам.
Приложение, которому требуется выполнить ввод/вывод, вызывает функцию open, чтобы создать дескриптор файла, применяемый для доступа к файлу. В операционной системе дескриптор файла реализован как массив указателей на внутренние структуры данных. Система сопровождает отдельную таблицу дескрипторов файлов для каждого процесса. При открытии файла процессом система помещает указатель на внутренние структуры данных для этого файла в таблицу дескрипторов файлов процесса и возвращает индекс таблицы в вызывающий оператор. В прикладной программе достаточно только присвоить этот дескриптор переменной и использовать его в последующих вызовах, которые запрашивают операции с файлами. Операционная система использует дескриптор как индекс таблицы дескрипторов процесса и переходит по указателю к структурам данных, содержащим всю информацию о файле. Таблица дескрипторов процесса используется для хранения указателей на внутренние структуры данных для файлов, открытых процессом. Процесс (приложение) использует дескриптор при обращении к файлу.
В API-интерфейсе сокетов реализовано новое абстрактное понятие для сетевой связи — сокет(IP-адрес плюс № порта, по), по которому устанавливается взаимодействие конкретных процессов на различных узлах сети. Как и файл, каждый активный сокет обозначается небольшим целым числом, называемым дескриптором сокета. Операционная система размещает дескрипторы сокетов в той же таблице дескрипторов, что и дескрипторы файлов. Поэтому в приложении не может присутствовать и дескриптор файла, и дескриптор сокета с одним и тем же значением.
В операционной системе предусмотрена отдельная системная функция socket, вызываемая приложением для создания сокета; функция open используется в приложении только для создания дескрипторов файлов. Общий замысел, который лег в основу разработки интерфейса сокетов, состоял в том, чтобы для создания любого сокета было достаточно одного системного вызова. Сразу после создания сокета приложение должно выполнить дополнительные системные вызовы для указания точных сведений о его назначении. Этот принцип можно пояснить, рассмотрев структуры данных, сопровождаемые системой.
Потоки и процессы
Приложение – самодостаточный набор машинных инструкций, обеспечивающий решение конкретной задачи. Процесс обычно определяют как экземпляр (или копию) выполняемой программы (приложения). В Win32 процессу отводится 4Гбайта адресного пространства. В этом адресном пространстве расположен exe-файл, код и данные DLL-библиотек. Кроме того, процессу принадлежат такие ресурсы, как файлы, динамические области памяти и потоки (thread). Ресурсы, которые создаются при жизни процесса, обязательно уничтожаются при его завершении.
В MSDN процесс определяется как контекст безопасности, в котором выполняется приложение. Обычно контекст безопасности связан с пользователем и приложения получают его уровень полномочий. (The security context under which an application runs. Typically, the security context is associated with a user, so all applications running under a given process take on the permissions and privileges of the owning user.)
Для того чтобы процесс что-либо выполнял, в нем обязательно должен быть хоят бы один поток. Поток можно определить как такой фрагмент программного кода, который выполняется последовательно. Именно потоки отвечают за исполнение программного кода, помещенного в адресное пространство процесса. При создании процесса в Win32 первый (первичный – primary) поток создается системой автоматически. Далее этот поток может порождать другие потоки, которые в свою очередь могут порождать третьи и т.д. Таким образом, процесс может включать произвольное число потоков, которые можно создавать и уничтожать. Процесс завершается, когда завершается выполнение первичного потока.
Приоритеты процессов и потоков. Операционная система распределяет процессорное время между потоками, выделяя каждому из них определенную долю времени (квант). Процессорное время выделяется по очереди каждому потоку, но при этом учитывается также приоритет потока. Когда прекращается выполнение первичного потока процесса, уничтожается и сам процесс.
Многопоточные процессы организуются в тех случаях, когда требуется избежать "узких" мест. Например, если процесс ожидает завершения файловой операции, связи с другим компьютером или просто вывода на экран какого-либо сложного изображения, то он попросту простаивает. В этом случае можно организовать отдельный поток или потоки, которые будут выполнять код параллельно; повысить скорость функционирования процесса в целом за счет того, что некритическая часть кода выполняется потоками с более низким приоритетом; использовать на полную мощь многопроцессорный компьютер. В этом случае каждый поток может исполняться на отдельном процессоре.
Интерфейс Win32 API позволяет управлять созданием и уничтожением потоков, распределением времени между потоками и приоритетами процессов и потоков. Процессы могут иметь классы приоритетов.
Классы приоритетов процессов
ABOVE_NORMAL_PRIORITY_CLASS
Больше NORMAL_PRIORITY_CLASS, нониже HIGH_PRIORITY_CLASS.
BELOW_NORMAL_PRIORITY_CLASS
Больше IDLE_PRIORITY_CLASS, нониже NORMAL_PRIORITY_CLASS.
HIGH_PRIORITY_CLASS
Высшийприоритет. Такой приоритет имеет, например, диспетчер задач Windows
IDLE_PRIORITY_CLASS
Низший приоритет (фоновый процесс). Такой процесс получит время только в том случае, если в системе нет других исполняемых потоков. Типичный пример – программа заставка.
NORMAL_PRIORITY_CLASS
Нормальный приоритет. Абсолютное большинство процессов, в том числе системных, имеют этот приоритет.
REALTIME_PRIORITY_CLASS
Самый высокий (реального времени) приоритет. Потоки этого процесса вытесняют все другие. Этот приоритет надо использовать с большой осторожностью и только на короткое время. К примеру, выполнение процесса с таким приоритетом «остановит» мышь или кеширование дисковых операций.
Функция Win API SetPriorityClass позволяет изменить приоритет процесса на этапе выполнения приложения:
BOOL SetPriorityClass(
HANDLE hProcess, // дескрипторпроцесса
DWORD dwPriorityClass // класс приоритета);
Класс реального времени используется только для процессов, которые, например, обрабатывают высокоскоростные потоки данных и завершаются за короткое время. Так как процесс реального времени имеет приоритет более высокий, чем большинство процессов ОС, то неаккуратное его использование может привести к зависанию системы.
Класс с высоким приоритетом также используется достаточно редко. Например, он может понадобиться в случае связи с каким-либо внешним устройством, которое, если не получит сигнал в течение короткого времени, отключается.
Большинство процессов выполняется с нормальным приоритетом. Это означает, что процесс не требует какого-либо повышенного внимания со стороны ОС.
Процессы с фоновым приоритетом получают время только в том случае, если у диспетчера задач нет других процессов. Примеры таких процессов – это программы-заставки, автосохранение или реорганизация данных и т.п.
Интерфейс Win32 API предлагает всего 32 уровня приоритета с номерами 0..31. Windows распределяет процессорное время между потоками в соответствии с их приоритетом, а не приоритетом процессов. (Процесс в Windows считается инертным, т.е. сам по себе он ничего не выполняет, а имеет смысл только при наличии в нем хотя бы одного потока.) При создании нового потока ему назначается такой же приоритет, как и у породившего его процесса. Вместе с тем приоритет потока можно изменять (свойство TThread.Priority в Delphi или функция Win API SetThreadPriority) при его создании или в процессе выполнения:
BOOL SetThreadPriority( HANDLE hThread, // дескрипторпотока int nPriority // приоритетпотока);
THREAD_PRIORITY_ABOVE_NORMAL
На 1 вышеприоритетапроцесса
THREAD_PRIORITY_BELOW_NORMAL
На 1 ниже приоритета процесса
THREAD_PRIORITY_HIGHEST
На 2 выше приоритета процесса
THREAD_PRIORITY_IDLE
Приоритет 1 дляклассовприоритетапроцесса IDLE_PRIORITY_CLASS, BELOW_NORMAL_PRIORITY_CLASS, NORMAL_PRIORITY_CLASS, ABOVE_NORMAL_PRIORITY_CLASS или HIGH_PRIORITY_CLASS.
Приоритет 16 для REALTIME_PRIORITY_CLASS.
THREAD_PRIORITY_LOWEST
На 2 ниже приоритета процесса
THREAD_PRIORITY_NORMAL
Приоритет потока совпадает с приоритетом процесса
THREAD_PRIORITY_TIME_CRITICAL
Приоритет 15 дляклассовприоритетапроцесса IDLE_PRIORITY_CLASS, BELOW_NORMAL_PRIORITY_CLASS, NORMAL_PRIORITY_CLASS, ABOVE_NORMAL_PRIORITY_CLASS или HIGH_PRIORITY_CLASS. Приоритет 31 для REALTIME_PRIORITY_CLASS
Примечание. Для Windows 2000/XP параметр nPriority может принимать также значения - 7, - 6, -5, - 4, - 3, 3, 4, 5 или 6. За дополнительной информацией обращайтесь к разделу Scheduling Priorities в справочной системе MSDN.
Одним из основных ресурсов любого компьютера является физическая память. Диспетчер памяти Windows наполняет память кодом и данными активных процессов, драйверов устройств и самой операционной системы. Так как в большинстве систем объем кода и данных, к которым производится обращение, превышает емкость физической памяти, то она демонстрирует, какой код и какие данные оказываются задействованы в тот или иной момент. Объем памяти влияет на производительность - когда данные или код, нужный процессу или операционной системе, отсутствует в памяти, диспетчер памяти вынужден подгружать его с диска.
Помимо воздействия на производительность, объем физической памяти обуславливает ограничения других ресурсов. К примеру, объем невыгружаемого пула (буферов операционной системы, выделяемых из физической памяти) напрямую зависит от объема физической памяти. Кроме того, характеристики физической памяти определяют предел виртуальной памяти системы, объем которой примерно равен сумме емкости физической памяти и максимального объема всех настроенных файлов подкачки. Наконец, объем физической памяти косвенно сказывается на максимальном количестве процессов. Об этом я подробно расскажу в предстоящей публикации об ограничениях, связанных с процессами и потоками.