Это зависит от конкретного устройства!
Например, принтер монополизируется до завершения печати документа.

чтобы с устройством можно было работать многопоточно - должен быть некий софт в самом устройстве или в ОС, который такую работу понимает. И так же само устройство должно быть заточено под такой функционал.

как правило, есть некоторый минимальный обьем, меньше которого нельзя распределять 1 ресурс между несколькими процессами. Для дисковых накопителей это сектор. Если процесс начал чтение сектора, то пока он чтение не закончит, другой процесс не может его прервать (в другом варианте более приоритетный процесс его прервать может, но тогда текущему процессу этот сектор надо будет читать заново). Вариант в скобках используется редко, и использовать его можно далеко не всегда, и не со всеми типами ресурсов.

Есть следующий подход -- процессам назначаются приоритеты. Если процесс захватывает ресурс, а потом процесс с более высоким приоритетом хочет захватить этот ресурс, то приоритет первого процесса временно повышается. Если еще кто-то приоритетный начинает хотеть этот ресурс -- приоритет первого процесса снова повышается до максимального из тех,кто хочет этот ресурс.

То есть, надо смотреть на конкретное устройство под конкретной ОС.

Програмёр
Из Вашего ответа следует, что ядро ОС вообще не имеет к этому процессу (работы с устройствами) никакого отношения (никак на него не влияет) и зависит только от драйвера. Значит и процесс обработки очереди описывается в драйвере и зависит только от него? Тогда интересно знать, как именно ведёт себя драйвер по-умолчанию (который с Windows поставляется)...



Конкретно, охватив весь список устройств, ответить на вопрос невозможно.

связка программа<->ядро ОС работает через api, и оно документировано

связка ядро ОС<->драйвер работает по унифицированному протоколу, который найти относительно реально. Любой производитель, делая железку и выпуская под нее драйвер, руководствуется такой документацией.

связка драйвер<->железка работает по условно-унифицированному протоколу, или по закрытому. В зависимости от железки. Найти его описание в общем случае нереально, однако если железка сделана с использованием широко распространенных микросхем, то можно найти документацию на эти микросхемы, в которой описывается апи как с ними работать. Но как именно конкретный драйвер использует это апи - сказать нельзя. Только путем реверс-инжиниринга. Есть такие любители, например на лоре в 2007 тип принялся писать драйвер принтера кэнон-номер_не_помню для линукса. Описания протокола нет, он все делал реверс-инжинирингом и к сегодняшнему дню он довольно сильно в этом деле продвинулся. Насколько помню, не так давно он хвастался, что уже может печатать документы, правда регулярно в печати встречаются полосы, избавиться от которых у него пока не вышло.

Конкретно про чтение файлов - можете искать описание протоколов ide, sata,и производных от них. Если интересно "какое-нибудь" чтение - можно найти исходинки работы с флешкой для embedded-систем, и поизучать.
Конкретно про работу с вводом-выводом на диск виндой и линукс -- большинство драйверов работает так: задачи бьются по секторам или группам секторов, и работа с ними исполняется или последовательно(скорей всего в hdd) или (если у нас sata в режиме achi) в ограниченное число потоков(в нормальных ssd). Число потоков, вероятно, зависит от конкретной модели винчестера.
При этом для некоторых задач (например форматирование) группой секторов может быть весь винчестер.

если протокол "ядро ОС<->драйвер" не допускает одновременную работу с ресурсом, то одновременной работы с ресурсом нет, а если допускает, то все зависит от драйвера, в котором это может быть реализовано, а может и нет.