Концепция процесса, потока

Процесс представляет собой экземпляр загруженной в память программ. ОС выделяет процессу адресное пространство, а также другие ресурсы: файлы с которыми работает программа, DLL – модули.

Процесс существует с момента создания и до момента завершения. Между этими моментами он может находиться в одном из состояний, которые являются наиболее важными: готовый к выполнению, выполняемый и заблокированный (рис.1.5.1).

Рис. 1.5.1. Диаграмма состояний процесса/потока

Процесс состоит из двух компонентов:

· объекта ядра, через который ОС управляет процессом. Там же хранится статистическая информация о процессе.

· адресного пространства, в котором содержится код и данные всех EXE и DLL модулей.

В данном адресном пространстве находятся:

· области стека,

· области данных,

· области программ,

· области для динамического распределения памяти и т.д.

Процесс работает в виртуальном адресном пространстве. Его отображение на физические адреса зависит от типа центрального процессора.

Рассмотрим распределение адресного пространства для ЦП RC36100.

32-х разрядное адресное пространство разделено на четыре части:

· kuseg диапазон адресов 0x0000 0000 – 0x7FFF FFFF;

· kseg0 диапазон адресов 0x8000 0000 – 0x9FFF FFFF;

· kseg1 диапазон адресов 0xA000 0000 – 0xBFFF FFFF;

· kseg2 диапазон адресов 0xC000 0000 – 0xFFFF FFFF;

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

· Kuseg транслируется в физическое адресное пространство размеров 2 ГВ, начиная с адреса 0х4000 0000. Это означает, что если старшие два разряда виртуального адреса равны «00», то они заменяются ЦП на значение «01», и значение «01» заменяется на значение «10», при этом остальные 30 разрядов адреса не изменяются;

· виртуальные адреса принадлежащие kseg2 отображаются прямо на соответствующие физические;

· виртуальные адреса, принадлежащие kseg0 и kseg1 отображаются на одни и те же диапазоны физических адресов.

Рис.1.5.2. Преобразование виртуальных адресов в физические

Способы отображения виртуальных адресов в физические зависит от того, как настроен блок управления памятью (MMU). Для ЦП RC36100 MMU может работать в двух режимах: фиксированного преобразования адресов FM (Fixed Mapped) и сегментно страничного отображение с использованием аппаратной таблицы ассоциативности TLB (Translation Lookaside Buffer).

Преобразование виртуальных адресов в физические в режиме FM показано на рисунке 1.5.2.

Выполняемый код процесса храниться во FLASH памяти в определенном формате, который зависит от типа используемого ЦП или микроконтороллера. В качестве примера, приведем краткое описания формата представления выполняемого кода процесса – ELF формат.

Elf файл состоит из следующих частей:

· заголовок;

· массив заголовков сегментов программы (N сегментов);

· бинарного кода сегментов;

· массива заголовков секций.

Каждый сегмент может состоять из различного числа секций.

Формат elf файла приведен на рисунке 1.5.3.

Формат заголовка elf файла

Elf32_Ehdr * HdrElf указатель на заголовок elfa

1. заголовок elfa, (const char *)HdrElf->e_ident;

HdrELF->e_ident[0] = (BYTE)0x7f;

HdrELF->e_ident[1] = (BYTE)'E';

HdrELF->e_ident[2] = (BYTE)'L';

HdrELF->e_ident[3] = (BYTE)'F'

2. Тип elfa, HdrElf->e_type;

HdrELF->e_type = ET_EXEC; // = 2 /* Executable file */

3. Аппаратная платформа, HdrElf->e_machine;

HdrELF->e_machine = EM_MIPS; // = 8 /* MIPS R3000 big-endian */

4. Номер версии, HdrElf->e_version;

HdrELF->e_version = EV_CURRENT; // = 1 /* Current version */

5. Точка входа. Виртуальный адрес, HdrElf->e_entry;

HdrELF->e_entry = 0xbfc0 0000

6. Смещение от начала файла таблицы заголовков сегментов, HdrElf->e_phoff;

HdrELF->e_phoff = sizeof(Elf32_Ehdr);

Окончание в следующем столбце	Окончание
Рис.1.5.3 Формат elf файла.

7. Расположение таблицы заголовков секций, HdrElf->e_shoff;

HdrElf->e_shoff = 0x0000d48d

8.Размер заголовка в байтах, HdrElf->e_ehsize;

HdrELF->e_ehsize = sizeof(Elf32_Ehdr);

9.Размер каждого заголовка сегментов программы, HdrElf->e_phentsize;

HdrELF->e_phentsize = sizeof(Elf32_Phdr);

10.Число заголовков сегментов программы, HdrElf->e_phnum;

HdrELF->e_phnum = 1;

11.Размер каждого заголовка секции, HdrElf->e_shentsize;

HdrELF->e_shentsize = sizeof(Elf32_Shdr);

12.Число заголовков секций, HdrElf->e_shnum;

HdrElf->e_shnum = 3;

13. Идекс секции, которая содержит имена других секций, HdrElf->e_shstrndx;

HdrElf->e_shstrndx = 2.

При запуске процесса на выполнение, его бинарный код переписывается в ОЗУ в зависимости от содержания заголовков секций и сегментов.

Формат заголовка сегмента elf файла

Elf32_Phdr *HdrSeg таблица заголовков сегментов программы

//1. тип сегмента

HdrSeg->p_type = PT_LOAD; //загружаемый сегмент в память

//2. смещение от начала файла, по которому находится первый байт сегмента =

HdrSeg->p_offset

//3. Виртуальный адрес сегмента

HdrSeg->p_vaddr

//4. Физический адрес сегмента

HdrSeg->p_paddr

//6.число байт в образе сегмента в памяти

HdrSeg->p_memsz

//5. число байт в образе сегмента в файле

HdrSeg->p_filesz

//7. Атрибуты сегмента.

//PF_R+PF_W+PF_X 7

//Чтение, запись, выполнение

HdrSeg->p_flags = 7;

//8. Выравнивание сегмента

HdrSeg->p_align

Формат заголовка секции elf файла

Elf32_Shdr *HdrSec - таблица заголовков сегментов программы

//1. Имя секции. Индекс первого символа в имени секции в таблице заголовков секций, которая содержится в секции с номером HdrElf->e_shstrndx;

HdrSec->sh_name

//2. Тип содержимого секции

HdrSec->sh_type = SHT_PROGBITS;

//3. атрибуты секции

//SHF_WRITE - секция содержит данные,которые д.б. доступны

//для записи во время выполнения процесса

//SHF_ALLOC -

//SHF_EXECINSTR - секция содержит исполняемый код

HdrSec->sh_flags = SHF_WRITE | SHF_ALLOC | SHF_EXECINSTR;

//4.адрес загрузки секции в память

HdrSec->.sh_addr

//5. смещение от начала файла, по которому находится первый байт секции

HdrSec->sh_offset

//6.размер секции в байтах

HdrSec->sh_size

//7.

HdrSec->sh_link = 0;

//8.

HdrSec->sh_info = 0;

//9.Выравнивание секции

HdrSec->sh_addralign;

//10.

HdrSec->sh_entsize = 0;

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

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

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

В каждом процесса всегда существует один поток, который автоматически создается ОС при создании процесса. Для того чтобы все потоки работали, ОС отводит каждому потоку определенное процессорное время, называемое квантами. За работу потоков и планирование их работы отвечает диспетчер задач.

Любой поток, также как и процесс, состоит из двух компонентов:

· объекта ядра, через который ОС управляет потоком. Там же хранится статическая информация о потоке.

· стека потока, который содержит параметры всех функций и локальные переменные необходимые, необходимые потоку для выполнения кода.

Таким образом в современных ОС РВ (QNX 6) задачи могут выполняется как потоках одного процесса, так и в потоках различных процессов. QNX 4 многопоточность не поддерживает, поэтому при работе под управлением данной ОС задачи выполняются в процессах.

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

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

При создании потока, ОС выделяет ему память под стек из адресного пространства процесса. Новый поток выполняется в контексте того же процесса, что и родительский поток. Поэтому он получает доступ ко всем дескрипторам объекта ядра, всей памяти и стекам всех потоков в процессе. За счет этого в границах одного процесса потоки могут легко взаимодействовать друг с другом.

У каждого потока есть собственный набор регистров процессора, называемый контекстом потока. Контекст отражает состояние регистров процессора на момент последнего исполнения потока.

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

На рисунке 1.5.4 показан контекст задачи для ЦП 1892ВМ2Т с системой команд MPIS - 32

typedef struct __RegCPU1892BM2T_DM{//структура данных регистров ЦП 1892ВМ2Т

uint at; uint v0; uint v1; uint a0;

uint a1; uint a2; uint a3; uint t0;

uint t1; uint t2; uint t3; uint t4;

uint t5; uint t6; uint t7; uint t8;

uint t9; uint k0; uint k1;

// uint r2;//разделитель 2

uint gp; uint sp; uint s8; uint ra;

uint hi; uint lo;

// uint r3;//разделитель 3

uint sr; /* CP0 Status register */

uint cause; /* CP0 Cause register */

uint epc; /* CP0 EPC register */

uint vaddr; /* CP0 BadVaddr register */

// uint r4;//разделитель 4

}_RegCPU1892BM2T_DM;

Рисунок 1.5.4 Контекст задачи для ЦП 1892ВМ2Т

Дата добавления: 2015-12-08