Проективные человеко-машинные системы. Проект как прообраз системы. Место пользователя в системе. Принципы построения.

Основные понятия операционной системы. Процессы. Взаимоблокировка Управление памятью. Ввод-вывод. Файлы. Безопасность

Ключевое понятие операционной системы — процесс. Процессом, по существу, называют программу в момент выполнения. С каждым процессом связывается его адресное пространство — список адресов в памяти от некоторого минимума до некоторого максимума, которые процесс может прочесть и в ко­торые он может писать. Адресное пространство содержит саму программу, данные к ней и ее стек. Со всяким процессом связывается некий набор регистров, включая счетчик команд, указатель стека и другие аппаратные регистры, плюс вся осталь­ная информация, необходимая для запуска программы.

Во многих операционных системах вся информация о каждом процессе, дополнительная к содержимому его собственного адресного пространства, хранит­ся в таблице операционной системы. Эта таблица называется таблицей процес­сов и представляет собой массив структур, по одной на каждый существующий в данный момент процесс.Главными системными вызовами, управляющими процессами, являются вызо­вы, связанные с созданием и окончанием процессов. Если процесс может создавать несколько других процессов (называющихся дочерними процессами), а эти процессы, в свою очередь, тоже могут создать дочер­ние процессы, перед нами предстает дерево процессов. Связанные процессы — это те, которые объединены для выполнения некоторой задачи, и им нужно часто передавать данные от одного к другому и синхронизиро­вать свою деятельность. Такая связь называется межпроцессным взаимодействи­ем. Другие системные вызовы предназначаются для запросов о предоставлении дополнительной памяти (или освобождении не использующейся памяти), ожида­нии завершения дочерних процессов и наложении одной программы на другую. Время от времени необходимо передавать информацию работающему процес­су так, чтобы он не простаивал в ожидании получения этой информации. Если по истечении определенного количества секунд ответа нет, операционная система посылает процессу сигнал тревоги. Сигнал вызывает временную оста­новку работы процесса независимо от того, что процесс делает в данный момент; сохраняет его регистры в стеке и запускает специальную процедуру обработки сигнала.

Каждому пользователю, которому разрешено пользоваться системой, системный администратор присваивает UID (идентификатор пользова­теля). У каждого работающего процесса есть идентификатор пользователя, запус­тившего его. Дочерний процесс получает тот же самый UID, что и его родитель. Пользователи могут становиться членами групп, каждая из которых имеет иден­тификатор группы (GID, Group IDentification).Пользователь с особым идентификатором UID, называемый в UNIX «супер­пользователем» (superuser), имеет особые полномочия и может игнорировать множество правил защиты. В огромных системах только системный администра­тор знает пароль, необходимый для того, чтобы стать суперпользователем.

Взаимоблокировка. Когда взаимодействуют два или более процессов, они могут попадать в патовые ситуации, из которых невозможно выйти без посторонней помощи. Такая ситуа­ция называется тупиком, тупиковой ситуацией или взаимоблокировкой.Тупиковую ситуацию легче всего представить с помощью примера из реально­го мира, с которым знаком каждый, — это пробки на дорогах. Четыре автобуса приближаются к перекрестку. За каждым автобу­сом есть еще машины. При определенном невезе­нии первые четыре автобуса прибудут на перекресток одновременно, рис. 1.2, б. Все автобусы заблокировали друг друга, поскольку ни один автобус не может двигаться вперед. При этом они не могут двигаться назад, потому что за ними есть еще автобусы. И нет простого способа выпутаться из этой ситуации.Компьютерные процессы могут попадать в аналогичные ситуации, в которых они не могут продвигаться дальше.

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

Ввод-вывод данных. Во всех компьютерах есть физическое устройство для получения входных данных и вывода информации. Существует много видов устройств ввода-вывода, например клавиатуры, мониторы, принтеры и т. д. Всеми ими долж­на управлять операционная система.Каждая операционная система имеет свою подсистему ввода-вывода для управ­ления устройствами ввода-вывода. Некоторые из программ ввода-вывода являют­ся независимыми от устройств, то есть их можно применить ко многим или ко всем устройствам ввода-вывода. Другая часть программного обеспечения ввода-выво­да, в которую входят драйверы устройств, предназначена для определенных уст­ройств ввода-вывода.

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

Перед тем как прочесть или записать файл, его нужно открыть, в это же время проверяется разрешение доступа. Если доступ разрешен, система возвращает не­большое целое число, называемое дескриптором файла и используемое в после­дующих операциях. Если доступ запрещен, то возвращается код ошибки.Специальные фай­лы служат для того, чтобы устройства ввода-вывода выглядели как файлы. Существует два вида специальных файлов: блочные специальные файлы и символьные специальные файлы. Блочные специальные файлы исполь­зуются для моделирования устройств, состоящих из набора произвольно адресуе­мых блоков, таких как диски. Открывая блочный специальный файл и читая, ска­жем, блок 4, программа может напрямую получить доступ к четвертому блоку на устройстве, без обращения к содержащейся на нем файловой системе. Таким же образом символьные специальные файлы используются для моделирования прин­теров, модемов и других устройств, которые принимают или выдают поток симво­лов. И последнее понятие, которое мы обсудим, — это каналы, имеющие отношение и к процессам и к файлам. Канал представляет собой псевдофайл, который можно использовать для связи двух процессов. Если процессы А и В захотят пообщать­ся с помощью канала, они должны установить его заранее. Когда процесс А хочет отправить данные процессу В, он пишет их в канал, как если бы это был выходной файл. Процесс В может прочесть данные, читая их из канала, как если бы он был файлом с входными данными. Таким образом, соединение между процессами в UNIX выглядит очень похожим на обычное чтение и запись файлов. Более того, только сделав специальный системный вызов, процесс может обнаружить, что выходной файл, в который он пишет данные, не реальный файл, а канал.

Безопасность. Компьютеры содержат большое количество информации, конфиденциальность которой пользователи зачастую хотят сохранить: электронную почту, бизнес-пла­ны и многое другое. В задачу операционной системы входит управление систе­мой защиты подобных файлов, так чтобы они, например, были доступны только пользователям, имеющим на это права. Кроме защиты файлов, существует еще множество других вопросов безопас­ности: защита системы от нежелательных гостей, людей, и не только (вирусов).

 

Принципы построения.

Принцип информационной открытости (И). Для существования и нормальной работы проективной системы очень важно, чтобы пользователь мог узнать все о работе любой ее части. Всякий инструмент должен быть документирован до степени, достаточной для понимания принципов его работы и всестороннего использования.Информационно открытая система отлично приспособлена для разработки и эксплуатации "в сообществе", то есть в ситуации, когда использовать, исправлять и развивать систему может, с формальной точки зрения, любой желающий, а на самом деле - именно тот, кому она нужна и кому это интересно. Еще одно достоинство информационно открытой системы заключается в том, что это единственная комфортная среда для любознательного человека. На любой вопрос он может найти ответ. Такое положение дел позволяет непрерывно совершенствовать профессиональный уровень, оставляя себе наибольшую степень свободы.

Принцип минимизации затрат (З). В человеко-машинной системе мыслительные функции стоит отдать человеку, а автоматические - машине. Более того, если человеко-машинная система вообще нуждается в человеке, то именно потому, что перед ней возникает известное число мыслительных задач, требующих решения. Ежели таковые имеются, все равно нужен кто-то, кто подтвердил бы их правильность. Значит, в хорошей проективной системе человек в основном должен решать мыслительные задачи, а механических, бездумных действий совершать как можно меньше. Обдуманные действия сопровождаются, как правило, определенным внутренним усилием, которого требует принятие на себя ответственности за их результат.Затраты на повторную реализацию будут существенно меньше. Если будущая задача будет похожа на уже решенную, достаточно только подправить проект. Если это будет та же самая задача, главное - оформить решение так, чтобы потом вспомнить, что это именно оно, и чтобы им могли воспользоваться другие. Принцип умопостижимости контекста (У). Для того чтобы задача могла быть решена, необходимо создать пользователю условия, в которых ее удобно решать. В частности, когда идет поиск решения и встает вопрос о выборе инструмента, очень важно отбросить как можно больше ненужных возможностей системы. Необходимо сократить контекст поиска до объема, который пользователь может целиком удерживать в голове. К сожалению, идеальной системы на свете нет. Однако и неидеальную систему следует разрабатывать с учетом ограниченных возможностей человеческой памяти и восприятия. Другая сторона принципа умопостижимости контекста: даже самый сложный проект должен быть в целом понятен пользователю. Это можно назвать требованием human readable: любой проект должен быть таким, чтобы пользователь мог прочесть его и понять целиком. Более строгое требование к проекту таково: достаточно опытный пользователь должен быть в силах не только просчитать, но и написать с нуля сложный проект.

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

 

 

Проективные человеко-машинные системы. Принцип информационной открытости (И). Принцип минимизации затрат (З). Принцип умопостижимости контекста (У). Принцип персональной ответственности (О). Следствия. Область применения

Принцип информационной открытости (И). Для существования и нормальной работы проективной системы очень важно, чтобы пользователь мог узнать все о работе любой ее части. Всякий инструмент должен быть документирован до степени, достаточной для понимания принципов его работы и всестороннего использования.

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

Принцип минимизации затрат (З). В человеко-машинной системе мыслительные функции стоит отдать человеку, а автоматические - машине. Более того, если человеко-машинная система вообще нуждается в человеке, то именно потому, что перед ней возникает известное число мыслительных задач, требующих решения. Ежели таковые имеются, все равно нужен кто-то, кто подтвердил бы их правильность. Значит, в хорошей проективной системе человек в основном должен решать мыслительные задачи, а механических, бездумных действий совершать как можно меньше. Обдуманные действия сопровождаются, как правило, определенным внутренним усилием, которого требует принятие на себя ответственности за их результат.Затраты на повторную реализацию будут существенно меньше. Если будущая задача будет похожа на уже решенную, достаточно только подправить проект. Если это будет та же самая задача, главное - оформить решение так, чтобы потом вспомнить, что это именно оно, и чтобы им могли воспользоваться другие. Принцип умопостижимости контекста (У). Для того чтобы задача могла быть решена, необходимо создать пользователю условия, в которых ее удобно решать. В частности, когда идет поиск решения и встает вопрос о выборе инструмента, очень важно отбросить как можно больше ненужных возможностей системы. Необходимо сократить контекст поиска до объема, который пользователь может целиком удерживать в голове. К сожалению, идеальной системы на свете нет. Однако и неидеальную систему следует разрабатывать с учетом ограниченных возможностей человеческой памяти и восприятия. Другая сторона принципа умопостижимости контекста: даже самый сложный проект должен быть в целом понятен пользователю. Это можно назвать требованием human readable: любой проект должен быть таким, чтобы пользователь мог прочесть его и понять целиком. Более строгое требование к проекту таково: достаточно опытный пользователь должен быть в силах не только просчитать, но и написать с нуля сложный проект.

Принцип персональной ответственности (О). Пользователь проективной системы берет на себя ответственность за качество проекта, а стало быть, и за поведение системы, собранной на основе этого проекта, и за качество получаемого продукта. Самая элементарная команда работы с системой предполагает, что человек сначала подумал и принял решение. Столь трепетное и уважительное отношение к мнению человека выливается в достаточно суровое правило "захотел - получил": что бы ни творил пользователь, предполагается, что делает он это сознательно. Второе правило: ответственность обусловлена знаниями. Хорошая проективная человеко-машинная система устроена так, что чем больше существует областей, в которых компетентен человек, тем больше он имеет возможностей изменять поведение системы, тем полнее управляет машиной. Пока вы не изучите основные принципы работы, скажем, процедур резервного копирования системных дисков, вы не сможете применять их. Или не станете, опасаясь взять на себя пока непосильную ответственность. И наоборот, если человек знает, как улучшить работу системы, эти знания надо использовать.Следствие 1. Очевидно, что основным направлением развития проективных систем будет создание все более мощных инструментариев, то есть наборов, позволяющих сравнительно быстро и эффективно строить решения задач в различных прикладных областях. Разнообразие инструментов не нарушает принцип У: вряд ли программисту придется использовать их все сразу. Скорее всего, он, сообразуясь с профилем решаемых задач и стилем работы, подберет небольшой, но мощный подходящий инструментарий. Для разработки больших проектов, которые должны "уметь все", программист выберет высокоуровневую среду, где ему придется иметь дело с более сложными, но умопостижимыми объектами, при необходимости спускаясь на более низкий уровень.

Следствие 2. Следует помнить четыре вещи. Во-первых, опыт и знание в проективной системе важнее конкретной поделки, так что ваши усилия не пропадут даром. Во-вторых, если не предвидится задач, которые ваша библиотека не решает, а чужая - решает, лучше оставить все как есть. В-третьих, когда чужая разработка объективно лучше, а задачи все прибывают, следует перейти на нее, если к тому нет формальных препятствий. И в-четвертых, когда в следующий раз приметесь изобретать велосипед, оглядитесь вокруг в поисках готовых мотоциклов, то есть поищите подходящий для ваших задач инструментарий.

Область применения.Проективные системы можно использовать для решения практически любых задач. Недостатки проективной системы: Во-первых, много времени может потребоваться на ее освоение, причем чем больше человек делает в системе, тем выше должна быть его квалификация; а за обучение, как и за квалификацию, надо платить. Принцип О предполагает, что каждый делает свое дело с полной ответственностью и принимает решения сам. Даже самые стандартные задачи проективная система выполняет всякий раз по-новому, потому что в ней заданы только параметры операций, а не сами операции. Количество циклов тестирование-отладка, которые придется пройти системе, прежде чем продукт ее будет признан качественным, зависит от опыта пользователя и строгости требований к продукту. В неудачных случаях задача так и остается нерешенной, гарантии решения нет никакой - кроме персональной гарантии самого пользователя и принципиальной разрешимости задачи. У принципа информационной открытости компьютерных человеко-машинных систем есть еще одно немаловажное следствие. Основной инструмент такой системы - программа или библиотека. Самый надежный источник информации о ней - исходный текст на языке программирования. Более того, только если программа доступна пользователю в виде исходного текста, он может находить в ней ошибки, исправлять и развивать ее. Если исходные тексты программного продукта недоступны, это бьет сразу по всем принципам организации проективной системы. Во-первых, это нарушение принципа И. Во-вторых, это сильно ограничивает О, так как затрудняет изменение продукта. Для этого придется выдумывать дополнительное информационно-открытое пространство внутри инструмента. При этом даже самое незначительное изменение свойств продукта может вылиться в дублирование этих свойств на "внутреннем языке", а тогда о З и говорить не приходится.

 

 

Процедурные человеко-машинные системы. Принцип ограниченной осведомленности. Принцип гарантированных навыков. Принцип перекрытия процедур. Принцип делегирования ответственности. Область применения. Недостатки процедурной системы.

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

Принцип гарантированных навыков.Пользователь не обязан что-то особенное уметь для того, чтобы начать работать с процедурной системой, а если чему-то для этого все-таки надо учиться, то хотелось бы научиться как можно быстрее. Поэтому взаимодействие с процедурной системой, как правило, основано на уже имеющихся у пользователя или совсем несложных навыках. Нельзя основной упор делать на команды, требующие от пользователя решения мыслительной задачи одним сложным действием, лучше если задача решается механическим повторением ряда простых действий.С другой стороны, задачу надо решать прямо сейчас и времени на то, чтобы разбираться, как сделать это решение изящным и эффективным, нет. В конце концов, что важнее - процесс или результат? Очевидно, результат. Значит, в качестве инструмента решения требуется нечто такое, что гарантированно можно пустить в ход в любой ситуации, не расходуя время на изучение инструкций.

Принцип перекрытия процедур.Любая задача должна быть хоть как-то решена. Поскольку любые сложные действия со стороны пользователя приветствуются, только если их можно описать на языке прикладной области, средства интеграции (совместного применения) самих процедур в процедурных системах развиты слабо. Следовательно, неизбежна ситуация, когда один класс типовых пользовательских задач решается при помощи одной группы процедур, другой класс задач - при помощи другой группы, но чем задача меньше похожа на типовую, тем сложнее придумать, какие процедуры и в какой последовательности применять, чтобы ее решить. Вывод: надо сами процедуры организовать так, чтобы с их помощью либо с помощью их суперпозиции можно было решить любую задачу. Это, конечно, невыполнимо, и стремление охватить предоставляемыми возможностями как можно большее пространство приводит к двум характерным свойствам системы.Во-первых, процедур в ней становится очень много. Чтобы пользователю легче было найти нужный рычаг, даже организуют специальные поисковые машинки. Иногда пункты меню располагаются так, что наглядность и простота не страдает, но это приводит к тому, что самое интересное оказывается труднодоступным и про него никто и не вспоминает. Во-вторых, многие задачи так и приходится решать: путем последовательного применения нескольких других решений, используя при этом только часть их свойств.

Принцип делегирования ответственности.Поскольку пользователь не имеет представления о том, что на самом деле происходит, когда он запускает очередную процедуру системы, гарантию качества выполняемых преобразований продукта может дать только разработчик процедуры. Пользователь может быть виноват лишь в том, что потянул не за тот рычаг, то есть на нем лежит ответственность за выбор процедуры. В еще большей степени от квалификации разработчика зависит качество получаемого продукта в целом: здесь разработчик отвечает и за непротиворечивость процедур системы, и за соответствие их работы стандарту, и за то, что все необходимые процедуры могут применяться именно тогда, когда они нужны, и за все остальное. Если процедуры слишком сложны, чтобы вдобавок отслеживать, не нарушают ли они какой-нибудь стандарт, проще вообще о нем забыть и придумать собственный. Мало того, пользователь процедурной системы в определенном смысле привыкает к безответственности. Типичный признак процедурной системы - обилие запросов на подтверждение выбранного действия. Иногда подтверждения бывают двойные: за первым "Вы уверены?" следует "Вы действительно уверены?". Ответственный за систему - разработчик - обязан таким способом отмечать точки управления системой, в которых он перекладывает ответственность на пользователя. Выходит, пользователю предпочтительнее быть неуверенным - так меньше вероятность, что он что-нибудь испортит.Применение: Основным направлением развития процедурных систем будет создание все более полных и сбалансированных наборов решений для все большего числа прикладных областей.

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

Недостатки процедурной системы.Один из них: подавление инициативы. Кроме всего прочего, человеку может быть чрезвычайно некомфортно работать в условиях, когда по своей воле он ничего ровным счетом сделать не в состоянии. К тому же подмена знаний о внутреннем устройстве системы легендой влечет за собой необратимость всякого воздействия: даже если в наборе процедур к "прямому" изменению объекта предусмотрено "обратное", после их поочередного применения исходный объект уже не получится. Скорее всего, он будет нести в себе следы прежнего объекта, а также и "прямого", и "обратного" изменений. Кроме того, как неизвестно, каким образом система работает, так неизвестно и то, каким образом она не работает, то есть отчего происходят ошибки, отчего именно это сочетание процедур приводит к сбою и т. п. Словом, невозможно предсказать, когда и как именно произойдет следующий сбой системы, а когда он произошел - понять, что его вызвало, и как с этим бороться. Наконец, чем дальше задача от типовой, тем сложнее ее такой системе решить и тем сложнее предсказать качество продукта, который получится в результате использования не вполне подходящих процедур.

Процедурные системы незаменимы там, где в основе взаимодействия человека с машиной лежит один из перечисленных выше принципов: если сложность устройства системы не соответствует выполняемым функциям, если необходима мгновенная отдача от неквалифицированного пользователя, если оператор системы не может брать на себя ответственность за качество ее работы. Идеальной была бы такая процедурная система, в которой процедуры перекрывались бы не более двух раз, интерфейс был бы нагляден, набор готовых решений охватывал бы все мыслимые задачи и не было бы понятно, как на самом деле все реализовано. Словом, система должна быть очень большой, у всех ее частей должен быть один разработчик и она сама должна "понимать", что человеку нужно, предлагая в разных ситуациях воспользоваться той или иной своей частью.

 

Использование потоков. Необходимость использования потоков. Примеры использования потоков. Текстовый редактор. Web-server. Обработка массивов данных. Модели создания сервера.

Необходимость использования потоков.Основной причиной является выполнение большинством приложений существенного числа действий, некоторые из которых могут время от времени блокироваться. Схему программы можно существенно упростить, если разбить приложение на несколько последовательных потоков, запущенных в квазипараллельном режиме.Еще одним аргументом в пользу потоков является легкость их создания и уничтожения (поскольку с потоком не связаны никакие ресурсы). Третьим аргументом является производительность. Концепция потоков не дает увеличения производительности, если все они ограничены возможностями процессора. Но когда имеется одновременная потребность в выполнении большого объема вычислений и операций ввода-вывода, наличие потоков позволяет совмещать эти виды деятельности во времени, тем самым увеличивая общую скорость работы приложения.И наконец, концепция потоков полезна в системах с несколькими процессорами, где возможен настоящий параллелизм.

Примеры использования потоков.

Текстовый редактор.Необходимость потоков проще продемонстрировать на конкретных примерах. Возьмем в качестве первого примера текстовый редактор.Представьте себе, что пользователь пишет книгу. С точки зрения автора проще всего хранить книгу в одном файле, чтобы легче было искать отдельные разделы, выполнять глобальную замену и т. п. С другой стороны, можно хранить каждую главу в отдельном файле. Но было бы крайне неудобно хранить каждый раздел и параграф в своем файле — в случае глобальных изменений пришлось бы редактировать сотни файлов. Например, если предполагаемый стандарт ххх был утвержден только перед отправкой книги в печать, придется заменять «Черновой стандарт ххх» на «Стандарт ххх» в последнюю минуту. Эта операция делается одной командой в случае одного файла и, напротив, займет очень много времени, если придется редактировать каждый из 300 файлов, на которые разбита книга.Теперь представьте себе, что произойдет, если пользователь удалит одно предложение на первой странице документа, в котором 800 страниц. Пользователь перечитал эту страницу и решил исправить предложение на 600-й странице. Он дает команду текстовому редактору перейти на страницу с номером 600 (например, задав поиск фразы, встречающейся только на этой странице). Текстовому редактору придется переформатировать весь документ вплоть до 600 страницы, поскольку до форматирования он не будет знать, где начинается эта страница. Это может занять довольно много времени и вряд ли обрадует пользователя.В этом случае помогут потоки. Пусть текстовый редактор написан в виде двух-поточной программы. Один поток взаимодействует с пользователем, а второй переформатирует документ в фоновом режиме. Как только предложение на первой странице было удалено, интерактивный поток дает команду фоновому потоку переформатировать весь документ. В то время как первый поток продолжает отслеживать и выполнять команды с клавиатуры или мыши — предположим, прокручивает первую страницу, — второй поток быстро переформатирует книгу.Раз уж мы об этом задумались, почему бы не добавить третий поток? Большинство текстовых редакторов автоматически сохраняет редактируемый текст раз в несколько минут, чтобы пользователь не лишился плодов работы целого дня в случае аварийного завершения программы, отказа системы или перебоев с питанием. Этим может заниматься третий поток, не отвлекая два оставшихся.

Web-server.Теперь давайте рассмотрим еще одну ситуацию, в которой необходимы потоки: сервер web-сайта. На сервер приходят запросы, и клиенту отсылается содержимое запрашиваемых web-страниц. У большинства web-сайтов некоторые страницы существенно более посещаемы, чем другие. Для повышения эффективности работы сервер использует эту особенность, храня содержимое особо популярных страниц в основной памяти. Этот раздел памяти называется кэш, и он используется также во многих других ситуациях.Один из способов организации web-сервера. Один поток, называемый диспетчером, считывает приходящие по сети запросы. После этого он находит свободный (то есть блокированный) рабочий поток и передает ему запрос, скажем, записывая указатель сообщения в специальное слово, связанное с каждым потоком. Затем диспетчер активизирует ждущий поток, переводя его из состояния блокировки в состояние готовности.После активации рабочий поток проверяет возможность удовлетворения запроса в кэше web-страниц, к которому имеют доступ все потоки. В случае отрицательного ответа поток начинает операцию чтения read, чтобы считать страницу с диска, и блокируется до завершения этой операции. Когда рабочий поток блокируется, для запуска выбирается следующий поток, им может оказаться диспетчер или другой готовый рабочий поток.Эта модель позволяет создать сервер в виде набора последовательных потоков. Программа диспетчера состоит из бесконечного цикла, в который входит получение запроса и передача его рабочему потоку. Программа каждого рабочего потока состоит из бесконечного цикла, включающего получение запроса от диспетчера и проверку кэша на наличие запрашиваемой страницы. При наличии страницы в кэше она отсылается клиенту, и рабочий процесс блокируется в ожидании нового запроса. При отсутствии страницы в кэше она считывается с диска, отсылается клиенту, и рабочий процесс блокируется в ожидании нового запроса.Возможен третий вариант web-сервера в случае существования версии системного запроса read без блокировки. На сервер приходит запрос, его считывает и проверяет единственный поток. Если запрашиваемая web-страница есть в кэше — хорошо, если нет — запускается дисковая операция без блокировки.

Сервер записывает в таблицу текущее состояние запроса и переходит к следующему событию. Оно может быть как новым запросом, так и ответом предыдущей операции. В случае нового запроса он начинает обрабатываться, в противном случае соответствующая информация считывается из таблицы и формируется ответ. В случае процедуры ввода-вывода с диска без блокировки ответ может иметь форму сигнала или прерывания.При такой схеме модель «последовательных процессов», которая была справедлива в первых двух ситуациях, не действует. Состояние программы должно явно сохраняться и восстанавливаться в таблице каждый раз, когда сервер переключается между запросами. Фактически мы имитируем потоки и стеки, причем не самым простым способом. Такая модель, в которой каждому расчету соответствует сохраненное состояние и есть несколько событий, которые могут изменить это состояние, называется машиной с конечным числом состояний или конечным автоматом. Эта модель широко используется в программировании.

Обработка массивов данных.Третий пример необходимости потоков — приложения, оперирующие большим количеством данных. Обычно считывается блок данных, обрабатывается и снова записывается. Проблема состоит в том, что при наличии только системных запросов с блокировкой процесс будет блокироваться при чтении и записи данных. Необходимо избегать простоя процессора, особенно при таком большом объеме вычислений.Решение проблемы — в потоках. Процесс можно разбить на входной поток, обрабатывающий поток и выходной поток. Входной поток считывает данные и помещает их во входной буфер. Обрабатывающий поток считывает данные из входного буфера, обрабатывает их и помещает в выходной буфер, а выходной поток считывает их оттуда и записывает обратно на диск. В тако