Реализация потоков в пространстве пользователя. Проблема блокирующих запросов

Реализация потоков в пространстве пользователя. Основные положения.

Метод основан на полном размещении всего пакета потоков внутри процесса, при этом ядро не знает о существовании многопоточности. Таким образом, реализовать многопоточность можно даже в однопоточных системах. Потоки должны работать поверх системы поддержки исполнения программ, которые являются набором структур данных и набором процедур, управляющих потоками, например функции creat, exit.

Каждому процессу необходима своя собственная таблица потоков, которая аналогична таблице процессов, но отслеживает только программный счетчик, регистры, состояния и другие характеристики потока. За счет того, что система поддержки исполнения программ реализована внутри процесса, создание потоков и переключение между ними выполняются с помощью небольшого количества команд без переключения в режим ядра. Если поток завершает либо приостанавливает свою работу, функции wait или yield могут сами сохранить информацию о потоке в таблице потоков, а так же вызвать внутренний планировщик для запуска следующего потока. У каждого процесса может быть свой собственный алгоритм планирования.

Основной проблемой, связанной с такой реализацией, является реализация блокирующих системных запросов. Специальные инструкции select или try проверяют, будет ли системный запрос блокирующим.

Выполнять блокирующий системный запрос неприемлемо, поскольку это заблокирует и все остальные потоки процесса. Одной из основных целей использования потоков является предоставление возможности каждому потоку использовать все системные запросы, таким образом, чтобы не мешать другим потокам. Одним из вариантов решения является превращение всех запросов в неблокирующие (например, read в случае неудачного чтения возвращает 0), но это потребует внесение изменений в ОС, что недопустимо. В некоторых операционных системах существует запрос select, который позволяет узнать о наличии блокировки у последующего запроса.

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

Еще одной проблемой реализации потоков в пространстве пользователя является тот факт, что переключение на новый поток не произойдет, пока рабочий поток добровольно не отдаст процессор. Это связано с тем, что внутри одного процесса нет прерываний по таймеру => невозможно создать планировщик.