Проста відповідь полягає в тому, що не всі потоки виконуються одночасно. Більш повне пояснення читайте далі.
Планувальник завдань операційної системи, як правило, продумує планувати програми, і це дозволяє вам виконувати одне завдання, коли комп'ютер працює над іншим. За старих часів лакмусовим тестом багатозадачності було форматування дискети, роблячи щось інше. Якщо ви хочете по-справжньому поставити ОС на тест, ви відформатували дискету під час завантаження файлу через модем, підключений до послідовного порту. Оскільки обладнання стало достатньо потужним, щоб насправді зробити це значущим чином, відтворення відео іноді містилось і в таких тестах. Якщо планувальник завдань ОС міг би без проблем виконувати виконання цих завдань, тоді він може впоратися з чим завгодно.
Однак планувальник завдань насправді не планує програми (процеси), він планує потоки . Кожна програма має щонайменше один потік, але потенційно може використовувати велику кількість потоків, щоб розділити роботу, яку вона виконує, на пов'язані або незалежні частини. Наприклад, для додатків прийнято мати один потік, який обробляє інтерфейс користувача, і створити інший потік, коли користувач ініціює потенційно тривалу операцію (це можуть бути такі речі, як друк, перерахунок електронної таблиці, середовище розробки пошук символів тощо тощо). Деякі середовища програмування вводять деяку кількість потоків, незрозумілих для програміста; наприклад, Java та .NET можуть збирати сміттяв окремий потік, який знаходиться поза безпосереднім контролем програміста. Деякі програми створюють низку потоків на початку та об'єднують їх, оскільки створення нових потоків є досить дорогою операцією (тому вам не обов’язково потрібно створювати нитку кожного разу, коли вам це потрібно). Все, що робить попередній перегляд, зазвичай робиться в окремому потоці, тому залишок інтерфейсу залишається чутливим під час створення попереднього перегляду. І так далі. У сукупності все це означає, що кількість потоків у системі в будь-який час може легко бути в багато разів більше процесів.
Кожна нитка може знаходитися в одному з декількох можливих станів, але найважливіша відмінність - стан, що працює , працює і очікує ; термінологія може дещо відрізнятися, але це загальна ідея. У будь-який момент часу тільки один потік на віртуальне (з - за гіперпоточності і подібних технологій) ядро процесора може бути запущений (тобто, виконуючи інструкцію машинного коду), але будь-яке число потоків може бути працездатним ( це означає , що він є кандидатом , щоб отримати наступного разу, коли планувальник повинен прийняти рішення про те, який потік потрібно дозволити запускати). Очікування (також відомий як заблоковані) потоки - це просто те, чекаючи чогось - найпоширеніші випадки, мабуть, це те, що він чекає вводу / виводу користувача, диска або мережі (зокрема, введення користувача надзвичайно повільне).
Кількість потоків, яку ви бачите в диспетчері завдань, - це загальна кількість потоків у будь-якому з цих станів. Наприклад, система Windows 7, яку я зараз набираю, має близько 70 запущених процесів, але майже 900 потоків. Оскільки всі фонові процеси для вирішення різних завдань і те, як вони, ймовірно, підрозділяються на безліч потоків кожна, це не є обурливим числом.
Трохи більше заглибившись у глибину технічної реалізації, в основі суті планувального завдання завдань операційної системи багатозадачності, як правило, це якийсь апаратний гачок переривання. Це означає , що ядро може зупинити CPU , коли він не має ніякої корисної роботи для виконання (це майже напевно одна з причин, якщо не причина, чому Linux перевіряє на інструкція по завантаженню на IA-32HLT-сумісні процесори та, ймовірно, аналогічні перевірки інших архітектур), безпечні, знаючи, що в певний розумний спосіб визначити майбутній час, буде перервано сигнал і планувальник завдань буде викликаний. Оскільки переривання спрацьовує незалежно від того, яку іншу роботу виконує процесор (така ідея переривань), планувальник регулярно виконується і отримує шанс визначити, який потік слід виконати протягом наступного часового відрізка. Оскільки контекстні комутатори є відносно дорогими, зазвичай можливо (принаймні через вихідний код) налаштувати, як агресивно планувальник перемикається між потоками; перемикання потоків частіше призводить до того, що система стає більш чуйною, але перемикання означає, що загальний час для виконання заданого набору завдань довший. швидкийсистема буде такою, яка перемикається між потоками лише тоді, коли запущений потік більше не можна запустити (це означає, що він заблокований, чекаючи чогось, або він закінчив свою роботу), оскільки це мінімізує накладні витрати, тоді як найвідповідальніша система переключатиметься між потоками щоразу, коли планувальник викликається, оскільки це мінімізує середній час очікування, перш ніж певний потік отримає час процесора. Ідеальна настройка зазвичай знаходиться десь між цими двома, і компроміс між цими варіантами, ймовірно, є однією з головних причин, чому Linux пропонує безліч планувальників на вибір, а також деякі параметри настройки через конфігурацію ядра.
З іншого боку, багатозадачні ОС і середовища, з іншого боку ( Windows 3.x є одним із прикладів), покладаються на кожну програму, щоб регулярно передавати контроль планувальнику. Зазвичай функція API, спеціально призначена для цього, і часто багато функцій API виконуватимуть це як частину внутрішнього потоку виконання, оскільки це допомагає зробити роботу користувача більш гладкою. Такий підхід до дизайну працює добре, якщо всі програми добре керуються та керують керуванням з короткими інтервалами під час будь-яких тривалих операцій (тривалий сенс означає більше невеликої частки секунди), але додаток, який не може засмітитися всієї системи. Це одна з основних причин, чому Windows 3.x так погано зробив тест на багатозадачність, про який я згадував вище, тоді як OS / 2весело прогулювались під час виконання одних і тих же завдань на одному і тому ж апараті: програма могла сказати накопичувачу дискети записати певний сектор, а час, необхідний для цього, перш ніж повернутись дзвінок, насправді можна виміряти (десятки до сотень мілісекунд або більше); система, що передує багатозадачність, повинна мати перерву планувальника під час наступного запланованого виклику, зауважте, що поток, який зараз "працює", фактично блокується викликом запису і просто переходить на інший потік, який можна виконати. (На практиці це трохи більше, але це загальна ідея.)
Як у превентивно багатозадачних, так і в кооперативних середовищах також існує можливість різних потоків, що мають різні пріоритети. Наприклад, мабуть, важливіше вчасно виконати потік, який отримує дані по комунікаційному каналу, ніж той, який оновлює відображення системного часу, тому приймальний потік має високий пріоритет, а потік оновлення відображення часу має низький пріоритет . Пріоритети нитки відіграють певну роль у рішенні планувальника, яку нитку дозволити виконувати (наприклад, дуже спрощено, потоки з високим пріоритетом завжди повинні виконуватися перед потоками з низьким пріоритетом, тому навіть якщо нитка з низьким пріоритетом залишається виконати роботу, якщо потік з високим пріоритетом стає запущеним, він має перевагу), але такі конкретні рішення щодо планування не впливають на основу конструкції механізму.