Для потоков, реализованных на уровне ядра, не требуется никаких новых, неблокирующих системных вызовов. Более того, если один из выполняемых потоков столкнется с ошибкой обращения к отсутствующей странице, ядро может с легкостью проверить наличие у процесса любых других готовых к выполнению потоков, и при наличии таковых, запустить один из них на выполнение, пока будет длиться ожидание извлечения запрошенной страницы с диска. Главный недостаток этих потоков состоит в весьма существенных затратах времени на системный вызов, поэтому если операции над потоками (создание, удаление и т. п.) проводятся довольно часто, то это влечет за собой более существенные издержки.
Когда многопоточный процесс выполняется на однопроцессорной системе, потоки выполняются, сменяя друг друга. На рис. 2.1 мы видели работу процессов в многозадачном режиме. За счет переключения между несколькими процессами система создавала иллюзию параллельно работающих отдельных последовательных процессов. Многопоточный режим осуществляется аналогичным способом. Центральный процессор быстро переключается между потоками, создавая иллюзию, что потоки выполняются параллельно, пусть даже на более медленном центральном процессоре, чем реально используемый. При наличии в одном процессе трех потоков, ограниченных по скорости вычисления, будет казаться, что потоки выполняются параллельно, и каждый из них выполняется на центральном процессоре, имеющем скорость, которая составляет одну треть от скорости реального процессора.
Существуют разные способы решения этой проблемы. Можно вообще запретить использование глобальных переменных. Какой бы заманчивой ни была эта идея, она вступает в конфликт со многими существующими программами. Другой способ заключается в назначении каждому потоку своих собственных глобальных переменных, как показано на рис. 2.14. В этом случае у каждого потока есть своя закрытая копия еггпо и других глобальных переменных, позволяющая избежать возникновения конфликтов. В результате такого решения создается новый уровень области определения, где переменные видны всем процедурам потока, вдобавок к уже существующим областям определений, где переменные видны только одной процедуре и где переменные видны из любого места программы.
Потоки часто используются в распределенных системах. Хорошим примером может послужить обработка входящих сообщений, к примеру запросов на обслуживание. Традиционный подход заключается в использовании процесса или потока, блокирующегося системным вызовом receive в ожидании входящего сообщения. По прибытии сообщения он его принимает, распаковывает, проверяет его содержимое и проводит дальнейшую обработку.
Но возможен также и совершенно иной подход, при котором поступление сообщения вынуждает систему создать новый поток для его обработки. Такой поток, показанный на рис. 2.12, называется всплывающим. Основное преимущество всплывающих потоков заключается в том, что они создаются заново и не имеют прошлого — никаких регистров, стека и всего остального, что должно быть восстановлено. Каждый такой поток начинается с чистого листа, и каждый их них идентичен всем остальным.
Работоспособность этой схемы определяется следующей основной идеей; когда ядро знает, что поток заблокирован (например, за счет выполнения блокирующего системного вызова или возникновения ошибки обращения к несуществующей странице), оно уведомляет принадлежащую процессу систему поддержки исполнения программ, передавая через стек в качестве параметров номер данного потока и описание произошедшего события. Уведомление осуществляется за счет того, что ядро активирует систему поддержки исполнения программ с заранее известного стартового адреса, — примерно так же, как действуют сигналы в UNIX. Этот механизм называется upcall (вызовом наверх).
