Модуль 11

Task states та життєвий цикл задачі

Ось готовий урок, створений спеціально для тебе у стилі CS50. Приготуйся, ми занурюємось у саме серце багатозадачності!

🎓 УРОК: Task States та Життєвий цикл задачі

Привіт, друзі! Я радий бачити вас тут.

Сьогодні ми поговоримо про магію. Ні, не про ту, що в Гоґвортсі, а про ту, яка відбувається у вашому смартфоні чи ноутбуці прямо зараз. Як вашому процесору вдається одночасно відтворювати музику, завантажувати файл з інтернету та реагувати на ваші натискання клавіш, якщо в нього (припустимо) лише одне ядро?

Відповідь криється в одній простій, але геніальній концепції: Стани задач (Task States).

1. 🔥 Вступ: Проблема та мотивація

Уявіть, що ви — єдиний кухар у дуже популярній піцерії 🍕. Це — ваша реальна ситуація.

У вас є три замовлення (це наші задачі): 1. Нарізати салямі. 2. Запекти тісто в печі (потрібно 10 хвилин). 3. Прийняти нове замовлення телефоном.

А тепер скажіть мені: чи будете ви стояти перед піччю і просто дивитися на тісто всі 10 хвилин, ігноруючи телефон, що дзвонить, і салямі, яке треба різати?

Звісно, ні! Це було б абсурдно. Поки тісто печеться, ви ріжете ковбасу. Поки ріжете — дзвонить телефон, ви відкладаєте ніж і відповідаєте.

У чому тут проблема? Якби комп’ютери не вміли перемикати задачі та керувати їхніми станами, ваш смартфон зависав би щоразу, коли ви очікуєте відповіді від сервера. Ви натиснули "Завантажити" — і все, екран не реагує, музика замовкла, життя зупинилося, доки файл не завантажиться.

Навіщо нам це потрібно? Щоб ми могли ефективно використовувати ресурси (ваш мозок або процесор CPU) і не змушувати користувача чекати дарма. Ми маємо навчитися жонглювати задачами.

2. 🧠 Теоретична база (без нудних лекцій)

Давайте заглянемо "під капот". У будь-якій операційній системі (чи то Windows, Linux, чи RTOS у мікроконтролері) є спеціальний менеджер. Його звати Планувальник (Scheduler).

Планувальник — це суворий адміністратор нашої піцерії. Він вирішує, яку задачу кухар (CPU) робить саме зараз. Але як він це вирішує? Він дивиться на СТАТУС (або стан) задачі.

Ось "Свята Трійця" станів, яку ви зобов'язані запам'ятати:

1. 🟢 Running (Виконується)

  • Що це: Задача прямо зараз володіє процесором. Код виконується.
  • Аналогія: Кухар ріже салямі ножем. Ніж у руках, робота йде.
  • Важливо: На одному ядрі в стані Running може бути тільки одна задача одночасно!

2. 🟡 Ready (Готова)

  • Що це: Задача хоче виконуватися, у неї є все необхідне, але процесор зайнятий кимось іншим (важливішим). Вона стоїть у черзі.
  • Аналогія: Салямі нарізана, тісто є. Піца готова до збірки, але Кухар (CPU) зараз зайнятий телефоном. Піца "чекає своєї черги".

3. 🔴 Blocked / Waiting (Заблокована / Очікує)

  • Що це: Задача не може виконуватися, навіть якби процесор був вільний. Вона чекає на якусь подію (прихід даних, натискання кнопки, таймер).
  • Аналогія: Піца в печі. Кухарю немає сенсу стояти над нею. Задача "Пекти піцу" заблокована таймером на 10 хвилин.

Інтуїтивне розуміння: Життя задачі — це постійний рух по колу: 1. Ти працюєш (Running). 2. Тобі треба почекати дані з диску? Ок, йди відпочинь (Blocked). 3. Дані прийшли? Чудово, ставай у чергу до процесора (Ready). 4. Планувальник побачив тебе в черзі і дав слово (Running).

3. 🧪 Приклади (від простого до реального)

Приклад 1: "Блимаємо світлодіодом" (Класика)

Завдання: Увімкнути світло, почекати 1 секунду, вимкнути.

  • Код новачка: LED_ON(); delay(1000); LED_OFF();
  • Що відбувається: Функція delay(1000) — це "активне очікування" (або busy wait). Процесор просто крутить порожній цикл.
  • Стан: Задача весь час Running, але робить дурницю. Вона не пускає нікого іншого.

Приклад 2: "Розумне очікування" (Як роблять профі)

  • Логіка: LED_ON(); OS_Delay(1000); LED_OFF();
  • Що відбувається: Коли ми викликаємо OS_Delay, ми кажемо Планувальнику: "Розбуди мене через 1000 мс".
  • Аналіз станів:
    1. LED_ON() -> Running.
    2. OS_Delay() -> Задача переходить у Blocked. Процесор вільний! Він йде робити корисні речі (наприклад, перевіряти Wi-Fi).
    3. Через 1000 мс -> Задача переходить у Ready.
    4. Планувальник бачить це і переводить у Running -> LED_OFF().

Приклад 3: Реальний кейс (YouTube Player)

Уявіть відеоплеєр. 1. Задача "Інтерфейс": Чекає, поки ви натиснете "Пауза". Більшість часу вона Blocked (чекає івенту мишки). 2. Задача "Мережа": Качає відео. Як тільки буфер повний, вона переходить у Blocked (нікуди складати). Як тільки буфер спорожнів — стає Ready -> Running. 3. Задача "Декодер": Бере дані з буфера і малює картинку.

Питання до вас: Що станеться з задачею "Декодер", якщо інтернет зникне і буфер стане порожнім? (Подумайте 5 секунд...)

Відповідь: Вона перейде в стан Blocked (очікування даних). Процесор не буде намагатися декодувати порожнечу, він піде економити заряд батареї.

4. 🛠 Практична частина

Час розім'яти мозок! 🏋️‍♂️

Завдання 1: Ідентифікація

Ви пишете програму для чату. Користувач почав друкувати повідомлення, але зупинився подумати. Програма чекає наступного натискання клавіші. У якому стані має перебувати задача обробки тексту? * А) Running * Б) Ready * В) Blocked

Завдання 2: Зміна умов

У вас є задача, яка зчитує температуру з датчика раз на хвилину. Якщо ви напишете код: while(Time < 1_minute) { /* нічого не робити */ } Це працюватиме? Так. Це ефективно? Виправте логіку, використовуючи поняття станів, щоб процесор міг спати цю хвилину.

Завдання 3: Міні-кейс "Зависання"

Ви написали гру. Але коли гравець зберігає гру (запис на диск), анімація героя на екрані завмирає на 2 секунди. Чому це сталося? (Підказка: згадайте про чергу Running). Як це вирішити архітектурно? (Підказка: скільки задач вам треба?)

Завдання 4: Питання "А що, якщо..."

А що, якщо у нас є дві задачі в стані Ready, і обидві дуже хочуть виконатися. Хто піде першим? (Спробуйте інтуїтивно здогадатися, яке поняття тут вступає в гру. Підказка: це як VIP-черга в аеропорту).

5. 💡 Мислення як у розробника

Ось де ми відокремлюємо новачків від сеньйорів.

Помилка новачка (Busy Waiting): Новачок думає: "Я хочу почекати, тому я напишу цикл for (int i=0; i<1000000; i++);". Це спалює електрику, нагріває процесор і блокує всі інші задачі (якщо система проста). Це як таксист, який намотує кола навколо кварталу, поки чекає пасажира, замість того, щоб припаркуватися.

Як думає досвідчений інженер: "Моїй задачі зараз є що робити? Ні? Тоді геть з процесора!". Досвідчений розробник завжди прагне перевести задачу в стан Blocked, якщо вона не робить корисної роботи прямо зараз. Це основа енергоефективності та чутливості системи (responsiveness).

Порада з практики: Ніколи не покладайтеся на те, що ваша задача буде Running вічно. Завжди пам'ятайте: Планувальник може забрати у вас процесор у будь-який мікросекундний момент. Пишіть код так, щоб він був готовий до переривань.

6. 🧩 Підсумок

Отже, що ми сьогодні розібрали?

  1. CPU — це дефіцитний ресурс. Ми не можемо витрачати його дарма.
  2. Три кити станів:
    • Running: Працюю.
    • Ready: Готовий працювати, чекаю черги.
    • Blocked: Чекаю на подію (не готовий працювати).
  3. Секрет плавності: Хороша програма більшість часу проводить у станах Blocked або Ready, даючи процесору "дихати".

Тепер ви вмієте: Розуміти, чому програма "тупить", і розрізняти, коли процесор зайнятий роботою, а коли — пустим очікуванням. Ви почали думати як архітектор системи, а не просто як кодер.

Що далі? У "Практичному завданні 4" ви замислились про VIP-чергу. На наступному уроці ми поговоримо про Пріоритети (Priorities) і страшного звіра, який називається Race Condition (Стан гонитви). Спойлер: це коли дві задачі б'ються за один шматок пам'яті, і перемагає хаос.

Це було CS50 (умовно). Побачимось на наступній лекції! 👋

← До списку уроків Наступний урок →