При використанні системного виклику, що не блокується, може опинитися, що потрібний пристрій вже зайнятий виконанням деяких операцій. Виклик, що в цьому випадку не блокується, може негайно повернутися, не виконавши запитаних команд. При організації запиту на здійснення операцій вводу-виводу за допомогою виклику, що блокується або асинхронного, зайнятість пристрою приводить до необхідності постановки запиту в чергу до даного пристрою. В результаті з кожним пристроєм виявляється зв'язаний список незадоволених запитів процесів, що знаходяться в стані очікування, і запитів, що виконуються в асинхронному режимі. Стан очікування розщеплюється на набір черг процесів, що чекають різних пристроїв вводу-виводу (або чекаючих зміни станів різних об'єктів – семафорів, черг повідомлень, умовних змінних в моніторах і так далі – див. лекцію 6).
Після завершення виконання поточного запиту операційна система (по ходу обробки виниклого переривання) повинна вирішити, який із запитів в списку має бути задоволений наступним, і ініціювати його виконання. Точно так, як і для вибору чергового процесу на виконання із списку готових нам доводилося здійснювати короткострокове планування процесів, тут нам необхідно здійснювати планування застосування пристроїв, користуючись яким-небудь алгоритмом цього планування. Критерії і цілі такого планування мало відрізняються від критеріїв і цілей планування процесів.
Завдання планування використання пристрою зазвичай покладається на базову підсистему вводу-виводу, проте для деяких пристроїв кращі алгоритми планування можуть бути тісно пов'язані з деталями їх внутрішнього функціонування. У таких випадках операція планування переноситься всередину драйвера відповідного пристрою, оскільки ці деталі приховані від базової підсистеми. Для цього в інтерфейс драйвера додається ще одна спеціальна функція, яка здійснює вибір чергового запиту, – функція strategy.