Системный процесс. Описание системного вызова

Список всех выполняемых на компьютере программ можно просмотреть с помощью Диспетчера задач Windows . Для этого необходимо нажать на клавиатуре сочетание клавиш . Вы увидите список процессов, и сразу возникнет вопрос: зачем нужен каждый конкретный процесс в этом списке? Давайте разберемся, что же такое процессы и как можно ими управлять.

Процессы – это все, что происходит в данный момент времени в системе. В Диспетчере задач на вкладке “Процессы” отображаются все запущенные на данный момент программы. Процессы могут быть “порождены” либо пользователем, либо системой. Системные процессы запускаются при загрузке Windows; пользовательские процессы – это программы, запущенные самим пользователем компьютера либо запущенные от его имени. Все системные процессы запускаются от имени LOCAL SERVICE , NETWORK SERVICE или SYSTEM (данная информация доступна в Диспетчере задач в столбце “Имя пользователя”).

Диспетчер задач позволяет только просматривать список процессов и завершать их работу. Для этого выделите имя процесса в списке и нажмите кнопку “Завершить процесс”.Это означает завершение работы программы, которой принадлежит процесс. Однако в Диспетчере задач невозможно просмотреть информацию о том или ином процессе.

Для управления процессами Windows я бы рекомендовал использовать более мощную утилиту, которая называется . Это отличная бесплатная программа, которая к тому же не требует установки. Скачиваем ее , затем запускаем из папки файл и выбираем сверху вкладку “Процессы”.
показывает все процессы в реальном времени, предоставляя исчерпывающую информацию по каждому из них. Щелкнув правой клавишей мыши по интересующему нас процессу и выбрав пункт “Свойства файла”, мы можем узнать производителя программного модуля, версию, атрибуты и другие сведения. Контекстное меню процесса также позволяет перейти в папку с программой, завершить процесс либо найти информацию о нем в интернете.

Как избавиться от вирусов на компьютере с помощью Starter?

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

Особое внимание уделите процессу, если тот запущен от имени пользователя и потребляет слишком много ресурсов (столбцы “ЦП” и “Память”). Если вы нашли в списке явно подозрительный процесс – завершите его и посмотрите, как после этого будет работать ваша система. Если же вы сомневаетесь или не знаете, какой программе принадлежит запущенный процесс – лучше зайдите в Google или Яндекс, введите в поисковой строке название процесса и найдите информацию о нем.

Встроенный в Windows Диспетчер задач конечно позволяет отключать процессы, но, к сожалению, дает очень мало информации по ним, а потому довольно сложно понять является ли процесс вирусным. Программа Starter в этом плане намного полезнее.

Итак, чтобы найти и удалить с компьютера вирусный процесс, делаем следующее :

1. Запускаем программу и переходим во вкладку “Процессы”.
2. Находим процесс, который вызывает у нас подозрения. Щелкаем по нему правой клавишей мыши и выбираем пункт “Свойства файла”. Я для примера выбрал файл svchost.exe . В открывшемся окне смотрим компанию-производителя данного приложения:
Дело в том, что практически любой процесс подписывается его разработчиком . А вот вирусные приложения как правило не подписаны.
В моем случае файл svchost.exe подписан компанией Microsoft Corporation и потому мы можем ему доверять.
3. Если выбранный процесс оказался никем не подписан или подписан какой-то странной компанией, то снова щелкаем правой клавишей по названию этого процесса и выбираем “Искать в Internet” – “Google” (интернет на компьютере при этом должен быть подключен).
4. Если на предложенных гуглом сайтах подтверждают, что данный процесс – вирусный, то необходимо перейти в папку этого процесса (для этого в Starter в контекстном меню выбираем пункт “Проводник в папку процесса”). Затем, предварительно завершив процесс, удаляем здесь файл этого процесса.
Если вы все таки сомневаетесь вирус это или нет (возможно вам не удалось посмотреть информацию о нем в Google в виду отсутствия интернета), то можете просто сменить расширение у данного файла (например, с.exe на.txt) и переместить его в другую папку.

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

Эта статья не является полным и подробным гидом по системным процессам Windows. Эта статья скорее может помочь определить какие из них настоящие, а какие – нет. вы спросите, как это может быть? Ответ очень прост. Что такое компьютерный вирус? По сути это простая программа, но она лишь вредит и работает без вашего ведома.

А для того, чтобы она работал, в системе необходимо запустить процесс. Зачастую вирус порождает новый процесс из системного, что может вызвать определённые проблемы. Но об этом ниже. Рекомендуется использовать программы для просмотра запущенных процессов в виде деревьев процессов, что упрощает распознование.

Итак, список «разрешённых», системных процессов и процессов. Иногда процессы запущенных вирусов генерируют название процесса, совпадающее с системным. Отличить их можно по аномально большому выделению памяти и возможности завершения. Такие процессы помечены восклицательным знаком.

explorer.exe – графическая оболочка. Стоит её отключить, и из средств управления системой у простого пользователя останется лишь сам диспетчер задач и командная строка(которую, впрочем, еще надо запустить).

internat.exe – подгружает в трей иконочку используемого языка. Лучше не трогать, хотя, в принципе, ничего критичного. taskmgr.exe – сам диспетчер задач. Если используете стороннюю программу, можете смело его вырубать, дабы не жрал системные ресурсы (ибо имеет наивысший приоритет).

(!)lsass.exe – генерирует метку пользователя для системы. Важный системный процесс. Отключить вручную невозможно. mstask.exe – планировщик задач. Бесполезен, но отключить тоже нельзя. smss.exe – отвечает за запуск сеанса для конкретного пользователя. Отключить невозможно.

(!)svchost.exe – процесс-источник для всех процессов, использующих DLL. Любимое гнездилище вирусов. Прежде чем отключать, надо смотреть, кто его вызвал и из какой папки. Нужно быть осторожным и не отключить какой-нибудь важный текущий процесс.

services.exe – менеджер системных сервисов. Выключить невозможно. Если вредоносный процесс порождён из него. поделать ничего уже не выйдет. Используйте антивирус.

system – процесс «ядра» системы. Соответственно, выключить тоже невозможно.

Таким образом, отличить вредоносный процесс возможно, хоть и не всегда это просто. Зачастую выполняемые файлы носят случайно сгенерированные имена (вроде x8er45yu67rw) или имена, которые должны вызвать у пользователя уверенность в том, что это компонент системы. Для предотвращения подобного обмана нужно знать, где и какой исполняемый файл находится (впрочем это относится лишь к самым основным процессам – их список вы можете прочесть выше). Но если «системный» процесс запущен не из папки WINDOWS, это уже является веской причиной для подозрения и выгрузки его из памяти. Тем не менее рекомендуется всегда использовать антивирус, так как простое удаление не всегда может помочь, вирусы зачастую изменяют реестр и системные файлы, и для отката необходимы системы антивируса. Однако эти знания могут пригодится вам, когда, например ваш компьютер заражен новым вирусом, запрещающим выход в интернет, но этого вируса нет в базе вашего антивируса. Тогда, очевидно, необходимо удалить процесс вируса, скачать обновление баз и удалить вирус уже полностью из самого антивируса.

Представлений

Теория П. К. Анохина как целостная система

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

Следует отметить, что когда некая теория уже четко сформулирована, при ретроспективном анализе литературы могут быть обнаружены высказывания, предвосхитившие какие-либо из набора ее положений. Такова ситуация и с ТФС. Так, Дж. Дьюи еще в конце прошлого века отмечал, что «действие детерминировано не предшествующими событиями, а потребным результатом» . В 20-е гг. XX столетия А. А. Ухтомский выдвигал положение о «подвижном функциональном органе», под которым понималось любое сочетание сил, приводящее к определенному результату. Тем не менее обоснованную не только теоретически, но и богатейшим экспериментальным материалом, целостную систему представлений мы находим именно в ТФС. Ее целостность и последовательность состоит в том, что идея активности, целенаправленности не просто включается в ТФС наряду с другими положениями, но, действительно, определяет основное содержание, теоретический и методический аппарат теории. Эта идея определяет и подходы к анализу конкретных механизмов достижения результата поведения, действующих на уровне целостного организма, и понимание организации активности отдельного нейрона (см. параграф 3). Как же отвечает ТФС на вопрос о механизмах, обеспечивающих объединение элементов в систему и достижение ее результата? Какие положения рефлекторной теории заставила отвергнуть П. К. Анохина (ученика И. П. Павлова) логика последовательного развития системных представлений, которая вывела ТФС за «рамки рефлекса» [Судаков, 1996]?

В качестве ключевых положений рефлекторной теории П. К. Анохин выделял следующие: а) исключительность пускового стимула как фактора, детерминирующего действие, которое является его причиной; б) завершение поведенческого акта рефлекторным действием, ответом и в) поступательный ход возбуждения по рефлекторной дуге. Все эти положения отвергаются при рассмотрении поведения с позиций ТФС [Анохин, 1978].

Наличие пускового стимула не является достаточным для возникновения адекватного поведения. Оно возникает: а) после обучения, т. е. при наличии соответствующего материала памяти; б) при наличии соответствующей мотивации и в) в соответствующей обстановке. Эти компоненты рассматривали, конечно, и другие авторы, но лишь как модуляторы или условия, при которых данный стимул вызывает данную, связанную с ним реакцию. П. К. Анохин же отмечал, что при появлении одного и того же стимула и изменении условий животное может достигать результата поведения самыми разными способами, никогда с этим стимулом не связывавшимися. Например, оно может использовать вместо подхода к кормушке подплывание к ней, если вода вдруг становится преградой.

Согласно ТФС, интеграция всех этих компонентов осуществляется в рамках специального системного механизма афферентного синтеза, в процессе которого на основе мотивации, при учете обстановки и прошлого опыта создаются условия для устранения избыточных степеней свободы - принятия решения о том, что, как и когда сделать, чтобы получить полезный приспособительный результат. Принятие решения завершается формированием акцептора результатов действия, который представляет собой аппарат прогнозирования параметров будущих результатов: этапных и конечного, и их сличения с параметрами результатов, реально полученных при реализации программы действия. При сличении с параметрами полученных этапных результатов выявляется соответствие хода выполнения программы запланированному (подробнее см. [Батуев, 1978; Пашина, Швырков, 1978]) при сравнении с параметрами конечного - соответствие достигнутого соотношения организма и среды тому, для достижения которого была сформирована система. Эти системные механизмы составляют операциональную архитектонику любой функциональной системы (рис. 14.1). Их введение в концептуальную схему - второе важнейшее преимущество и признак, отличающий ТФС от других вариантов системного подхода.

Рис. 14.1. Функциональная система и поведенческий континуум

Операциональная архитектоника функциональной системы по П. К. Анохину (вверху). О системных механизмах, составляющих операциональную архитектонику, см. параграф 2. Стрелки от «доминирующей мотивации» к «памяти» демонстрируют, что характер информации, извлекаемой из памяти, определяется доминирующей мотивацией. Схема также иллюстрирует представление о том, что в акцепторе результатов действия содержатся модели этапных результатов наряду с конечным результатом и что модель последнего представлена не единичной характеристикой, а комплексом параметров

Поведенческий континуум (внизу). Р n , Р n+1 - результаты поведенческих актов; р 1,2,3 - этапные результаты; Т- трансформационные процессы (см. параграф 2). О наборах систем, обеспечивающих реализацию последовательных актов континуума, и о вовлечении в трансформационные процессы систем, не участвующих в реализации актов, смена которых данными процессами обеспечивается (эти системы обозначены незаштрихованными овалами), см. в параграфе 7

Формирование в ТФС представления о том, что интеграция элементарных физиологических процессов осуществляется в рамках качественно отличных от них специфических системных процессов, имело принципиальное значение для развития психофизиологического подхода к анализу поведения и деятельности, а также системного решения психофизиологической проблемы (см. параграф 5). Разработка представлений о качественной специфичности процессов интеграции явилась открытием нового вида процессов в целостном организме - системных процессов, организующих частные физиологические процессы, но не сводимых к последним.

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

В стабильных условиях, например в ситуации лабораторного эксперимента, появление пускового стимула делает возможной реализацию предпусковой интеграции, которую можно охарактеризовать как готовность систем будущего поведения, формирующуюся в процессе выполнения предыдущего. Она направлена в будущее, но стабильность ситуации делает очевидной связь «стимул-ответ». Однако анализ нейронной активности в поведении четко показывает, что организация последней определяется тем, какой результат достигается в данном поведении, тогда как стимул лишь «разрешает» реализацию поведения. В тех случаях, когда один и тот же по физическим параметрам стимул «запускает» разные поведенческие акты (например, пищедобывательный или оборонительный), разными в этих актах оказываются не только характеристики активности нейронов, но даже и сам набор вовлеченных клеток, в том числе и в «специфических» по отношению к стимулу областях мозга (например, в зрительной коре при предъявлении зрительного стимула; см. [Швыркова, 1979; Александров, 1989]).

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

Наконец, ТФС отвергает положение о поступательном ходе возбуждения по дуге рефлекса. В соответствии с этим положением, реализацию поведения обеспечивает активация последовательно включающихся в реакцию структур мозга: сначала сенсорных структур, обрабатывающих сенсорную информацию, затем эффекторных структур, которые формируют возбуждение, активирующее железы, мышцы и т. д. Однако нами [Александров, Швырков, 1974], а также работами лабораторий Дж. Олдса и особенно Е. Р. Джона (см. в ) было показано, что при реализации поведенческого акта имеет место не последовательное включение афферентных и эфферентных структур, а синхронная активация нейронов, расположенных в самых разных областях мозга. Паттерн активаций нейронов в этих структурах оказывается общим, имеет общемозговой характер. Компоненты этого паттерна - последовательные фазы активации - соответствуют последовательности развертывания описанных ранее системных механизмов (см. [Швырков, 1978, 1995]). Сказанное касается не только нейронов головного мозга. Например, было обнаружено, что в латентном периоде поведенческого акта (см. ниже о трансформационных процессах), задолго до начала его реализации и синхронно с нейронами головного мозга, перестраивается активность элементов, которые принято связывать исключительно с «исполнительными» механизмами: мышечные единицы, рецепторы мышечных веретен [Александров, 1989].

Уже более тридцати Лет назад было очевидно важнейшее значение феномена синхронности. С позиций рефлекторной теории предполагалось, что синхронность дистантных структур обеспечивает улучшение проведения возбуждения по дуге рефлекса. С позиций же ТФС был сделан вывод о том, что это феномен - свидетельство синхронного вовлечения элементов различной анатомической локализации в системные процессы. Эти процессы - общеорганизменные и не могут быть локализованы в какой-либо области мозга или в какой-либо части тела. В различных областях мозга в поведенческих актах протекают не локальные афферентные или эфферентные, а одни и те же общемозговые системные процессы организации активности нейронов в систему, которая является не сенсорной или моторной, а функциональной. Активность нейронов этих областей отражает не обработку сенсорной информации или процессы регуляции движений, а вовлечение нейронов в определенные фазы организации (афферентный синтез и принятие решения) и реализации системы. Активность любой структуры одновременно соответствует как определенным свойствам среды, так и характеру двигательной активности [Швырков 1978; Швырков, Александров, 1973].

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

Единый паттерн активаций и синхронность вовлечения нейронов разных областей мозга в общемозговые системные процессы не означают эквипотенциальности (равнозначности) мозговых структур; вклад этих структур в обеспечение поведения зависит от специфики проекции на них индивидуального опыта (см. параграф 8).

В качестве ключевых положений рефлекторной теории П.К. Анохин выделял следующие:

1. исключительность пускового стимула как фактора, детерминирующего действие, которое является его причиной;

2. завершение поведенческого акта рефлекторным действием, ответом;

3. поступательный ход возбуждения по рефлекторной дуге.

Все эти положения отвергаются при рассмотрении поведения с позиций ТФС [Анохин, 1978].

Наличие пускового стимула не является достаточным для возникновения адекватного поведения. Оно возникает: а) после обучения, т.е. при наличии соответствующего материала памяти; б) при наличии соответствующей мотивации и в) в соответствующей обстановке. Эти компоненты рассматривали, конечно, и другие авторы, но лишь как модуляторы или условия, при которых данный стимул вызывает данную, связанную с ним реакцию. П.К. Анохин же отмечал, что при появлении данного стимула и изменении условий животное может достигать результат поведения самыми разными способами, никогда с этим стимулом не связывавшимися. Например, оно может использовать вместо подхода к кормушке подплывание к ней, если вода вдруг становится преградой.

Согласно ТФС, интеграция всех этих компонентов осуществляется в рамках специального системного механизма афферентного синтеза, в процессе которого на основе мотивации, при учёте обстановки и прошлого опыта создаются условия для устранения избыточных степеней свободы – принятия решения о том, что, как и когда сделать, чтобы получить полезный приспособительный результат. Принятие решения завершается формированием акцептора результатов действия, который представляет собой аппарат прогнозирования параметров будущих результатов: этапных и конечного, и их сличения с параметрами результатов, реально полученных при реализации программы действия. При сличении с параметрами полученных этапных результатов выявляется соответствие хода выполнения программы запланированному (подробнее см. [Батуев, 1978; Пашина, Швырков, 1978]) при сравнении с параметрами конечного – соответствие достигнутого соотношения организма и среды тому, для достижения которого была сформирована система. Эти системные механизмы составляют операциональную архитектонику любой функциональной системы (рис. 14.1). Их введение в концептуальную схему – второе важнейшее преимущество и признак, отличающий ТФС от других вариантов системного подхода.

Формирование в ТФС представления о том, что интеграция элементарных физиологических процессов осуществляется в рамках качественно отличных от них специфических системных процессов, имело принципиальное значение для развития психофизиологического подхода к анализу поведения и деятельности, а также системного решения психофизиологической проблемы (см. параграф 5). Разработка представлений о качественной специфичности процессов интеграции явилась открытием нового вида процессов в целостном организме – системных процессов, организующих частные физиологические процессы, но несводимых к последним.

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

В стабильных условиях, например в ситуации лабораторного эксперимента, пусковой стимул реализует готовую предпусковую интеграцию, которую можно охарактеризовать как готовность систем будущего поведения, формирующуюся в процессе выполнения предыдущего. Она направлена в будущее, но стабильность ситуации делает очевидной связь «стимул–ответ». Однако анализ нейронной активности в поведении чётко показывает, что организация последней определяется тем, какой результат достигается в данном поведении, тогда как стимул лишь «запускает», «разрешает» реализацию. В тех случаях, когда один и тот же по физическим параметрам стимул «запускает» разные поведенческие акты (например, пищедобывательный или оборонительный), разными в этих актах оказываются не только характеристики активности нейронов, но даже и сам набор вовлечённых клеток, в том числе и в «специфических» по отношению к стимулу областях мозга (например, в зрительной коре при предъявлении зрительного стимула; см. [Швыркова, 1979; Александров, 1989]).

Рис. 14.1. Функционольная система и поведенческий континуум

Операциональная архитектоника функциональной системы по П.К. Анохину (вверху). О системных механизмах, составляющих операциональную архитектонику, см. параграф 2. Стрелки от «доминирующей мотивации» к «памяти» демонстрируют, что характер информации, извлекаемой из памяти, определяется доминирующей мотивацией. Схема также иллюстрирует представление о том, что в акцепторе результатов действия содержатся модели этапных результатов наряду с конечным результатом и что модель последнего представлена не единичной характеристикой, а комплексом параметров.

Поведенческий континуум (внизу). Р n’, Р n+1 – результаты поведенческих актов; p1,2,3, – этапные результаты; Т– трансформационные процессы (см. параграф 2). О наборах систем, обеспечивающих реализацию последовательных актов континуума (каждому набору соответствует свой тип штриховки) и о вовлечении в трансформационные процессы систем, не участвующих в реализации актов, смена которых данными процессами обеспечивается (эти системы обозначены незаштрихованными овалами), см. в параграфе 7

Второе положение рефлекторной теории, которое отвергается ТФС, – оценка действия как завершающего этапа поведенческого акта. С позиций ТФС заключительный этап развёртывания акта – сличение прогнозируемых в акцепторе параметров с параметрами реально полученного результата. Если параметры соответствуют прогнозируемым, то индивид реализует следующий поведенческий акт; если же нет, то в аппарате акцептора возникает рассогласование, ведущее к перестройке программ достижения результата.

Наконец, ТФС отвергает положение о поступательном ходе возбуждения по дуге рефлекса. В соответствии с этим положением, реализацию поведения обеспечивает активация последовательно включающихся в реакцию структур мозга: сначала сенсорных структур, обрабатывающих сенсорную информацию, затем эффекторных структур, которые формируют возбуждение, активирующее железы, мышцы и т.д. Однако многочисленными экспериментами было показано, что при реализации поведенческого акта имеет место не последовательное включение афферентных и эфферентных структур, а синхронная активация нейронов, расположенных в самых разных областях мозга. Паттерн активации нейронов в этих структурах оказывается общим, имеет общемозговой характер. Компоненты этого паттерна – последовательные фазы активации – соответствуют последовательности развёртывания описанных ранее системных механизмов (см. [Швырков, 1978, 1995]). Экспериментальные результаты, подтверждающие данные о синхронности активации нейронов в поведении, продолжают накапливаться и в последнее время , и им придаётся всё большее значение в понимании не только организации дефинитивного поведения, но и обучения.

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

Единый паттерн активации и синхронность вовлечения нейронов разных областей мозга в общемозговые системные процессы не означают эквипотенциальности (равнозначности) мозговых структур; вклад этих структур в обеспечение поведения зависит от специфики проекции на них индивидуального опыта (см. параграф 8).

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

Реализация системных вызовов должна удовлетворять следующим требованиям:

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

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

Для обеспечения высокой скорости полезно использовать векторные свойства системы программных прерываний, имеющиеся во многих процессорах, т.е. закрепить за каждым системным вызовом определенное значение вектора. Приложение при таком способе вызова непосредственно указывает в аргументе запроса значение вектора, после чего управление немедленно передается требуемой процедуре ОС (рис. 3.5, а). Однако этот децентрализованный способ передачи управления привязан к особенностям аппаратной платформы, а также не позволяет ОС легко модифицировать набор системных вызовов и контролировать их использование. Например, в процессоре Pentium количество системных вызовов определяется количеством векторов прерываний, выделенных для этой цели из общего пула в 256 элементов (часть которых используется под аппаратные прерывания и обработку исключений). Добавление нового системного вызова требует от системного программиста тщательного поиска свободного элемента в таблице прерываний, которого к тому же на каком-то этапе развития ОС может и не оказаться.

В большинстве ОС системные вызовы обслуживаются по централизованной схеме, основанной на существовании диспетчера системных вызовов (рис. 3.5, б). При любом системном вызове приложение выполняет программное прерывание с определенным и единственным номером вектора. Например, ОС Linux использует для системных вызовов команду INT 80h, а ОС Windows NT (при работе на платформе Pentium) - INT 2Eh. Перед выполнением программного прерывания приложение тем или иным способом передает операционной системе номер системного вызова, который является индексом в таблице адресов процедур ОС, реализующих системные вызовы (таблица sysent на рис. 3.5, б). Способ передачи зависит от реализации. Например, номер можно поместить в определенный регистр общего назначения процессора или передать через стек (в этом случае после прерывания и перехода в привилегированный режим их нужно будет скопировать в системный стек из пользовательского, это действие в некоторых процессорах автоматизировано). Также некоторым способом передаются аргументы системного вызова, они могут как помещаться в регистры общего назначения, так и передаваться через стек

Рис. 3.5. Децентрализованная (а) и централизованная (б) схемы обработки

системных вызовов

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

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

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

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

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

Для ускорения некоторых достаточно простых системных вызовов, которым к тому же не нужен привилегированный режим, требуемая работа полностью выполняется библиотечной функцией, которую несправедливо называть в данном случае заглушкой. Точнее, такая функция не является системным вызовом, а представляет собой «чистую» библиотечную функцию, выполняющую всю свою работу в пользовательском режиме в виртуальном адресном пространстве процесса, но прикладной программист может об этом и не знать - для него системные вызовы и библиотечные функции выглядят единообразно. Прикладной программист имеет дело с набором функций прикладного программного интерфейса - API (например, Win32 или POSIX), состоящего и библиотечных функций, часть которых пользуется для завершения работы системными вызовами, а часть нет.

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

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

Асинхронный системный вызов не приводит к переводу процесса в режим ожидания после выполнения некоторых начальных системных действий, например запуска операции вывода/вывода, управление возвращается прикладному процессу (рис. 3.6, б).

Рис. 3.6. Синхронные (а) и асинхронные (б) системные вызовы

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

Блок управления процессом

Для того чтобы ОС могла управлять процессами, она должна располагать всей необходимой для этого информацией. С этой целью на каждый процесс заводится специальная информационная структура, содержащая определенную важную информацию о процессе и называемая дескриптором процесса (блоком управления процессом - Process Control Block, PCB). В общем случае дескриптор процесса содержит следующую информацию:

идентификатор процесса (так называемый PID - Process IDentificator);
тип (или класс) процесса, который определяет для супервизора некоторые правила предоставления ресурсов;
приоритет процесса, в соответствии с которым супервизор предоставляет ресурсы. В рамках одного класса процессов в первую очередь обслуживаются более приоритетные процессы;
переменную состояния, которая определяет, в каком состоянии находится процесс (готов к работе, в состоянии выполнения, ожидание устройства ввода/вывода и т.д.);
защищенную область памяти (или адрес такой зоны), в которой хранятся текущие значения регистров процессора, если процесс прерывается, не закончив работы. Эта информация называется контекстом задачи (процесса);
информацию о ресурсах, которыми процесс владеет и/или имеет право пользоваться (указатели на открытые файлы, информация о незавершенных операциях ввода/вывода и т. п.);
место (или его адрес) для организации общения с другими процессами;
параметры времени запуска (момент времени, когда процесс должен активизироваться, и периодичность этой процедуры).

Таким образом, в блоке управления процессом ОС может сосредоточить всю ключевую информацию о процессе.

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

Процессы в ОС UNIX. Все построение ОС UNIX основано на использовании концепции процессов. Контекст процесса складывается из пользовательского контекста и контекста ядра, как изображено на рис. 3.7.

Под пользовательским контекстом процесса понимают код и данные, расположенные в адресном пространстве процесса. Все данные подразделяются:

на инициализируемые неизменяемые данные (например, константы);
инициализируемые изменяемые данные (все переменные, начальные значения которых присваиваются на этапе компиляции);
^инициализируемые изменяемые данные (все статические переменные, которым не присвоены начальные значения на этапе компиляции);

Рис. 3.7.

стек пользователя;
данные, расположенные в динамически выделяемой памяти (например, с помощью стандартных библиотечных С функций mallocO, callocO, reallocO).

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

Под понятием «контекст ядра» объединяются системный контекст и регистровый контекст. Выделим в контексте ядра стек ядра, который используется при работе процесса в режиме ядра (kernel mode), и данные ядра, хранящиеся в структурах, являющихся аналогом блока управления процессом - РСВ. В данные ядра входят: идентификатор пользователя - UID, групповой идентификатор пользователя - G1D, идентификатор процесса - P1D, идентификатор родительского процесса - PP1D.

Идентификация процесса. Каждый процесс в ОС получает уникальный идентификационный номер - P1D (process identificator).

При создании нового процесса ОС пытается присвоить ему свободный номер больший, чем у процесса, созданного перед ним. Если таких свободных номеров не оказывается (например, достигнут максимально возможный номер для процесса), то ОС выбирает минимальный номер из всех свободных номеров. В ОС Linux присвоение идентификационных номеров процессов начинается с номера 0, который получает процесс kernel при старте ОС. Этот номер впоследствии не может быть присвоен никакому другому процессу. Максимально возможное значение для номера процесса в Linux на базе 32-разрядных процессоров Intel составляет 2 31 -1.

Состояния процесса. Краткая диаграмма состояний. Модель состояний процессов в ОС UNIX представляет собой детализацию модели состояний. Диаграмма состояний процессов в ОС UNIX изображена на рис. 3.8.

Состояние процесса «исполнение» расщепилось на два состояния: «исполнение в режиме ядра» и «исполнение в режиме пользователя». В состоянии «исполнение в режиме пользователя» процесс выполняет прикладные инструкции пользователя. В состоянии «исполнение в режиме ядра» выполняются инструкции ядра ОС в контексте текущего процесса (например, при обработке сис-

Рис. 3.8. Краткая диаграмма состояний процесса в UNIX темного вызова или прерывания). Из состояния «исполнение в режиме пользователя» процесс не может непосредственно перейти в состояния «ожидание», «готовность» и «закончил исполнение». Такие переходы возможны только через промежуточное состояние «исполняется в режиме ядра». Также запрещен прямой переход из состояния «готовность» в состояние «исполнение в режиме пользователя».

Приведенная выше диаграмма состояний процессов в UNIX не является полной. Она показывает только состояния, для понимания которых достаточно уже полученных знаний.

Иерархия процессов. В ОС UNIX все процессы, кроме одного, создающегося при старте ОС, могут быть порождены только какими-либо другими процессами. В качестве прародителя всех остальных процессов в подобных UNIX системах могут выступать процессы с номерами 1 или 0. В ОС Linux таким родоначальником, существующим только при загрузке системы, является процесс kernel с идентификатором 0.

Таким образом, все процессы в UNIX связаны отношениями «процесс-родитель - процесс-ребенок» и образуют генеалогическое дерево процессов. Для сохранения целостности генеалогического дерева в ситуациях, когда процесс-родитель завершает свою работу до завершения выполнения процесса-ребенка, идентификатор родительского процесса в данных ядра процесса-ребенка (PPID - parent process identificator) изменяет свое значение на значение 1, соответствующее идентификатору процесса init, время жизни которого определяет время функционирования ОС. Тем самым процесс init как бы усыновляет осиротевшие процессы. Наверное, логичнее было бы заменять PPID не на значение 1, а на значение идентификатора ближайшего существующего процесса- прародителя умершего процесса-родителя, но в UNIX почему-то такая схема не была реализована.

Системные вызовы де1рр1с!() и де1ртс1()

Данные ядра, находящиеся в контексте ядра процесса, не могут быть прочитаны процессом непосредственно. Для получения информации о них процесс должен совершить соответствующий системный вызов. Значение идентификатора текущего процесса может быть получено с помощью системного вызова §е1р1с1(), а значение идентификатора родительского процесса для текущего процесса - с помощью системного вызова getppid(). Прототипы этих системных вызовов и соответствующие типы данных описаны в системных файлах и. Системные вызовы не имеют параметров и возвращают идентификатор текущего процесса и идентификатор родительского процесса соответственно.

Прототипы системных вызовов

#include ttinclude pid_t getpid(void); pid_t getppid(void);

Описание системных вызовов

Системный вызов getpid возвращает идентификатор текущего процесса. Системный вызов getppid возвращает идентификатор процесса-родителя для текущего процесса.

Тип данных pid_t является синонимом для одного из целочисленных типов языка С.

Создание процесса в UNIX. Системный вызов fork()

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

идентификатор процесса - PID;
идентификатор родительского процесса - РРШ. Дополнительно может измениться поведение порожденного

процесса по отношению к некоторым сигналам.

Системный вызов для порождения нового процесса

Прототип системного вызова

#include ttinclude pid_t fork(void);

Описание системного вызова

Системный вызов fork служит для создания нового процесса в операционной системе UNIX. Процесс, который инициировал системный вызов fork, принято называть родительским процессом (parent process). Вновь порожденный процесс принято называть процессом-ребенком (child process). Процесс-ребенок является почти полной копией родительского процесса. У порожденного процесса по сравнению с родительским изменяются значения следующих параметров:

идентификатор процесса;
идентификатор родительского процесса;
время, оставшееся до получения сигнала SIGALRM;
сигналы, ожидавшие доставки родительскому процессу, не будут доставляться порожденному процессу.

При однократном системном вызове возврат из него может произойти дважды: один раз в родительском процессе, а второй раз в порожденном процессе. Если создание нового процесса произошло успешно, то в порожденном процессе системный вызов вернет значение 0, а в родительском процессе - положительное значение, равное идентификатору процесса-ребенка. Если создать новый процесс не удалось, то системный вызов вернет в инициировавший его процесс отрицательное значение.

Системный вызов fork является единственным способом породить новый процесс после инициализации ОС UNIX.

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

Завершение процесса. Функция ех1Ч()

Существует два способа корректного завершения процесса в программах, написанных на языке С. Первый способ мы использовали до сих пор: процесс корректно завершался по достижении конца функции main() или при выполнении оператора return в функции main(), второй способ применяется при необходимости завершить процесс в каком-либо другом месте программы. Для этого используется функция exit () из стандартной библиотеки функций для языка С. При выполнении этой функции происходит сброс всех частично заполненных буферов ввода/вы- вода с закрытием соответствующих потоков, после чего инициируется системный вызов прекращения работы процесса и перевода его в состояние «закончил исполнение».

Значение параметра функции exitQ - кода завершения процесса - передается ядру ОС и может быть затем получено процессом, породившим завершившийся процесс. На самом деле при достижении конца функции main() также неявно вызывается эта функция со значением параметра 0.

Функция для нормального завершения процесса

Прототип функции

«include void exit(int status);

Описание функции

Функция exit служит для нормального завершения процесса. При выполнении этой функции происходит сброс всех частично заполненных буферов ввода/вывода с закрытием соответствующих потоков (файлов, pipe, FIFO, сокетов), после чего инициируется системный вызов прекращения работы процесса и перевода его в состояние закончил исполнение.

Возврата из функции в текущий процесс не происходит, и функция ничего не возвращает.

Значение параметра status - кода завершения процесса - передается ядру ОС и может быть затем получено процессом, породившим завершившийся процесс. При этом используются только младшие 8 бит параметра, так что для кода завершения допустимы значения от 0 до 255. По соглашению, код завершения 0 означает безошибочное завершение процесса.

Если процесс завершает свою работу раньше, чем его родитель, и родитель явно не указал, что он не хочет получать информацию о статусе завершения порожденного процесса, то завершившийся процесс не исчезает из системы окончательно, а остается в состоянии «закончил исполнение» либо до завершения процесса-родителя, либо до того момента, когда родитель получит эту информацию. Процессы, находящиеся в состоянии «закончил исполнение», в ОС UNIX принято называть процессами-зомби (zombie, defunct).

Категории

Популярное