1.

У яких ситуаціях під час розробки програмного забезпечення

доцільніше використовувати модель процесів, а не модель потоків?
Розробляти і налагоджувати багатопотокові програми складніше, ніж
звичайні послідовні програми; досить часто впровадження багатопотоковості
призводить до зниження
надійності застосувань. Організація спільного використання адресного
простору декількома потоками вимагає, щоб програміст мав високу
кваліфікацію.
Використання потоків може спричинити зниження продуктивності додатків.
Переважно це трапляється в однопроцесорних системах (наприклад, у таких
системах спроба виконати складний розрахунок паралельно декількома
потоками призводить лише до зайвих витрат на перемикання між
потоками, кількість виконаних корисних інструкцій залишиться тією ж
самою).
2.Для трьох станів потоків — виконання, готовності й очікування — перелічіть
усі можливі переходи зі стану в стан і назвіть причини таких переходів.
Скажіть також, які переходи неможливі, та поясніть чому. У якому зі станів
потоки перебувають найдовше?

Коли програма обробляється, вона створює певний шлях.

Потім їй виділяються необхідні ресурси, і вона отримує статус готовності.
Коли планувальник потоків призначає потік процесору, він надходить у
чергу виконання.
Коли процес потребує запуску іншої події, яка перебуває поза його
контролем він переходить з виконання на очікування.
Коли ж інша подія завершилася, статус змінюється на виконання.
Після завершення процесу потік переходить від виконання до закінчення.
На мою думку неможливий перехід від статусу готовності до закінчення.
На цьому етапі вилізе помилка, бо без ніяких дій не буде відбуватися будь-
який процес.
Найдовше потоки перебувають у стані виконання.
3. У чому полягає головний недолік реалізації таблиці процесів у вигляді
масиву? Які альтернативні варіанти її реалізації можна запропонувати?
Головним недоліком є те, що таблиця процесів у вигляді масиву вимагає
багато місця. Альтернативою є вертикальне розміщення даних, оскільки це
фактично одномірний масив вертикальний (є тільки один стовпчик), який
містить показники тільки по одному процесу. Це фактично кожний рядок
таблиці процесів, але відокремлений і не прив'язаний до єдиної системи
4.Після одержання від браузера запиту веб-сервер створює новий процес для
його обслуговування і продовжує очікувати наступних запитів. Розробник
сервера виявив, що після
обробки кожного запиту в системі залишається процес-зомбі. Дайте
відповіді на такі запитання:
а) у чому причина появи такого процесу і наскільки серйозна ця проблема з
погляду витрат
пам'яті?
б) як виправити код сервера, щоб процеси-зомбі не виникали?

а) 1 частина Коли процес завершується, його керуючий блок не

вилучається зі списку й хеша процесів негайно, а залишається там доти,
поки інший процес (предок) не видалить його звідти. Якщо процес
насправді в системі відсутній (він завершений), а є тільки його керуючий
блок, то такий процес називають процесом-зомбі (zombie process).
Зомби не занимают памяти (как процессы-сироты), но блокируют записи в
таблице процессов, размер которой ограничен для каждого пользователя и
системы в целом.
б) Щоб цього уникнути, необхідно скористатися тим, що під час
завершення процесу-нащадка процес-предок отримує спеціальний сигнал
SIGCHLD. Якщо в оброблювачі цього сигналу викликати waitpidO, то це
призведе до вилучення інформації про процес-нащадок з таблиці процесів,
внаслідок чого зомбі в системі не залишиться.