ак Абстракція «Завдання» ( job) має НЕ Дуже загальний характер. Вона булу спеціально створами для групування процесів з метою! Застосування обмежень до прісутніх в них потоках, таких як обмеження Використання ресурсів с помощью спільно вікорістовуваної квоти або! Застосування маркера ОБМЕЖЕНОЮ доступу (restricted token), Який НЕ дозволяє потокам Звертатися до багатьох системних об'єктів. Найважлівішою властівістю Завдання (в плані управління ресурсами) є ті, Що з того моменту, як процес оказался в завданні, ВСІ створені (у ціх процесах) потоками Процеси будут такоже перебуваті в цьом завданні. Виходе немає. У повній відповідності Зі своєю Божою Назв Завдання були прізначені для таких СИТУАЦІЙ, Які швідше нагадував пакетну Обробка Завдання, чем звічайні інтерактівні обчислення.
Процес может знаходітіся всередіні Тільки для одного Завдання (максимум).
Рис. 1.3.1.1. Зв'язок между Завдання, процесами, потоками и волокнами.
На рис. 1.3.1.1. показань зв «язок между Завдання (jobs), процесами (processes), потоками (threads) i волокнами (fibers). Завдання містять процеси. Процеси містять потоки. Альо потоки не містять волокна. Зв »язок между потоками и волокнами зазвічай має тип« багато-до-багатьох ».
Волокна створюються путем віділення місця в стеку и структурованих Даних волокна в режімі користувача (для зберігання регістрів и Даних, пов'язаних з Цім волокном). Потоки перетворюються у волокна, однак волокна могут створюватіся и Незалежності від потоків. Такі волокна не будут Виконувати до тихий ПІР, поки ті что Вже віконується в потоці волокно на вікліче явно SwitchToFiber (для запуску волокна). Потоки могут спробуваті переключітісь на ті волокно, Яке Вже віконується, так что програміст винен Передбачити сінхронізацію (щоб унікнуті цього Явища). Основною ПЕРЕВАГА волокон є ті, что витрати перемикань между волокнами набагато нижчих, чем перемикань между потоками. Для перемикань между потоками треба Войти в ядро?? І вийти з нього. Перемикань между волокнами зберігає и відновлює кілька регістрів (без усякої Зміни режиму).
Для Спрощення взаємодії между потоками и волокнами часто Буває корисностей створюваті Рівно стількі потоків, Скільки є процесорів для їх Виконання, а такоже аффінізуваті потоки (щоб КОЖЕН Потік працював Тільки на ПЄВНЄВ наборі процесорів або взагалі Тільки на одному процесорі ).
Будь-який процес зазвічай ПОЧИНАЄТЬСЯ з одного потоку, однак можна дінамічно создать додаткові. Потоки є основою планування процесора, оскількі операційна система всегда вібірає для Виконання Потік, а не процес. Отже, КОЖЕН Потік має стан (готова, віконується, блокованій и т. д.), а Процеси НЕ мают станів планування. Потоки можна створюваті дінамічно помощью виклику Win32, в якому вказується адреси в адресному просторі процеса (з Якого ВІН винен почінаті роботу).
Коженая Потік має ідентифікатор потоку, Який вібірається з того ж простору, что й ідентифікатор процеса (так что процес и Потік Ніколи НЕ могут мати однакове ідентифікатор). Ідентіфікаторі процесів и потоків кратні ЧОТИРИ, оскількі смороду віділяються виконавчим рівнем (з використаних спеціальної табліці опісувачів, прізначеної для віділення ідентіфікаторів).
Зазвічай Потік віконується в режімі користувача, проти Колі ВІН Робить системний виклик, ВІН ...
