Последний раз обновлено 11.02.014
Наверное последний вопрос сегодня это реализация сущностей модульности и многозадачности: процесс, нить и модуль.
Для реализации процессов, нитей и модулей на конкретной машине требования по прозрачности сегментов те же самые что для реализации адресного пространства, т.е. в терминах архитектуры х86, существование контекста процесса, нити и модуля означает, что доступ к каждому контексту во время работы метода модуля осуществляется без перезагрузки сегментных регистров.
Обычно всегда сравнивают между собой процессы и нити, при этом появление нити для процесса обычно означает, что появляется некий дополнительный сегмент данных, который для каждой нити свой.
Посмотрим на следующую таблицу, которая показывает, как количество независимых аппаратных сегментов данных для архитектуры х86 влияет на богатство возможных сочетаний (количество разных конфигураций) для процесса, нити и модуля.
Таблица: число независимых сегментов данных и исполнимый формат Exx:
--1 сегмент (для 16 бит есть поддержка компиляторов для DOS)
E20 тяжелые нити, плоская память (нет отдельного сегмента кода), SP protected
E21 тяжелые нити, SP protected
--2 сегмента (286)
E22 нити, *IPC раздельные пространства процесса
E23 тяжелые нити +раздельные пространства модулей
E24 тяжелые нити +1 фреймы стека, *IPC раздельные пространства модулей
--3 сегмента (386)
E30 нити +1 фреймы стека, *IPC раздельные пространства процесса
--4 сегмента (386)
E40 нити +раздельные пространства модулей
E41 нити +1 фреймы стека +раздельные пространства нити
E42 нити +2 фреймы стека, *IPC раздельные пространства процесса
--5 сегментов (нет процессора архитектуры х86)
E50 нити +1 фреймы стека +раздельные пространства модулей
--6 сегментов (нет процессора архитектуры х86)
E60 нити +2 фреймы стека +раздельные пространства модулей
--7 сегментов, селекторы с четырьмя таблицами (нет процессора архитектуры х86)
E70 нити +2 фреймы стека +раздельные пространства модулей +защита записи +2 рабочих регистра _IU_DATAЗдесь "тяжелые нити" это эмуляция общих данных процесса через IPC (через дополнительный сегмент). Хотя такое соглашение не соответствует идеологии "идеальной нити", это приходится терпеть, потому что реальные процессоры с одним/двумя независимыми сегментами данных существуют, а "тяжелая нить" все равно лучше, чем "легкий процесс". Функции помеченные (*) опциональны, дают ограниченные в применении расширения тоже через дополнительный сегмент.
Кроме этих сегментов в архитектуре х86 еще есть регистр ES, который в этой таблице всегда играет роль рабочего, а также, еще есть регистр CS, который содержит код, поэтому для х86 общее число сегментных регистров в процессоре равно указанному в таблице плюс 2.
Как видите, портируемая программа абстрактной машины С дополнительно должна явно выбрать формат многозадачности, исходя из количества независимых сегментов данных в системе, на которой программа способна будет отработать с желаемой эффективностью.
Формат многозадачности определяет интерфейс сервиса, который программа может запрашивать у системы. Программа формата E20 не сможет слинковаться, если попробует создавать нити, т.е. исполнимый формат Exx определяет только качественные возможности интерфейса, виды динамических библиотек. Конкретный интерфейс, форматы заголовков и т.п. определяется типом ОС, в которой предполагается выполнять приложение.
Если для процессора аналогичного 386 все сущности многозадачности так или иначе (почти) поддержаны, для процессоров с меньшим количеством аппаратных сегментов и разрядности, этот выбор особенно важен.
Хотя в данной таблице для определенности сегменты приведены для архитектуры х86, это не важно какая именно архитектура и как именно реализованы сегменты. Формат E20 это плоская модель любого процессора, а формат E40 это возможности 386 процессора или лучше. Формат E40 не сможет исполняться с ожидаемой эффективностью (без эмуляции какого-либо рода) на процессоре хуже, чем 386.
Такой самоцели, как запускать все приложения в мире на 16 битном окружении, конечно нет, но если модули данной портируемая программы не требуют типов данных или адресных сегментов размером более 16 бит, то такая программа должна работать на любом реальном 16 битном окружении (то же самое для границы в 32 бита); если этого не происходит, программа написана плохо, как минимум в плане портируемости.