ЖУРНАЛ СТА 2/1997

приложения может одновременно происходить и набор текста, и про верка правописания. Преимущества потоков 1. Так как множество потоков способ- но размещаться внутри одного ЕХЕмодуля, это позволяет эко- номить ресурсы как внешней, так и внутренней памяти. 2. Использование потоками общей об- ласти памяти позволяет эффектив- но организовать межзадачный обмен сообщениями (достаточно передать указатель на сообщение). Процессы не имеют общей области памяти, поэтому ОС должна либо целиком скопировать сообщение из области памяти одной задачи в область па- мяти другой (что для больших сооб- щений весьма накладно), либо пред- усмотреть специальные механизмы, которые позволили бы одной зада- че получить доступ к сообщению из области памяти другой задачи. 3. Как правило, контекст потоков меньше, чем контекст процессов, а значит, время переключения между задачамипотоками меньше, чем между задачамипроцессами. 4. Так как все потоки, а иногда и са- мо ядро РВ размещаются в одном ЕХЕмодуле, значительно упроща- ется использование программ отладчиков (debugger). Недостатки потоков 1. Как правило, потоки не могут быть подгружены динамически. Чтобы добавить новый поток, необходимо провести соответствующие измене- ния в исходных текстах и переком- пилировать приложение. Процессы, в отличие от потоков, подгружаемы, что позволяет динамически изме- нять функции системы в процессе ее работы. Кроме того, так как процес- сам соответствуют отдельные про- граммные модули, они могут быть разработаны различными компани- ями, чем достигается дополнитель- ная гибкость и возможность исполь- зования ранее наработанного ПО. 2. То, что потоки имеют доступ к об- ластям данных друг друга, может привести к ситуации, когда некор- ректно работающий поток способен испортить данные другого потока. В отличие от этого процессы защи- щены от взаимного влияния, а по- пытка записи в «не свою» память при- водит, как правило, к возникновению специального прерывания по обра- ботке «исключительных ситуаций». Реализация механизмов управления процессами и потоками, возможность их взаимного сосуществования и взаи- модействия определяются конкрет- ным ПО РВ. ОСНОВНЫЕ СВОЙСТВА ЗАДАЧ Как правило, вся важная, с точки зре- ния операционной системы, информа- ция о задаче хранится в унифициро- ванной структуре данных — управляю- щем блоке (Task Control Block, TCB). В блоке хранятся такие параметры, как имя и номер задачи, верхняя и нижняя границы стека, ссылка на очередь сооб- щений, статус задачи, приоритет и т. п. Приоритет — это некое целое чис- ло, присваиваемое задаче и характе- ризующее ее важность по сравнению с другими задачами, выполняемыми в системе. Приоритет используется в ос- новном планировщиком задач для оп- ределения того, какая из готовых к ра- боте задач должна получить управле- ние. Различают системы с динамичес- кой и статической приоритетностью. В первом случае приоритет задач мо- жет меняться в процессе исполнения, в то время как во втором приоритет задач жестко задается на этапе разра- ботки или во время начального кон- фигурирования системы. Контекст задачи — это набор дан- ных, содержащий всю необходимую информацию для возобновления вы- полнения задачи с того места, где она была ранее прервана. Часто контекст хранится в ТСВ и включает в себя та- кие данные, как счетчик команд, указа- тель стека, регистры СРU и FPU и т. п. Планировщик задач в случае необходи- мости сохраняет контекст текущей ак- тивной задачи и восстанавливает кон- текст задачи, назначенной к исполне- нию. Такое переключение контекстов и является, по сути, основным механиз- мом ОС РВ при переходе от выполне- ния одной задачи к выполнению другой. Состояние (статус) задачи . С точ- ки зрения операционной системы, за- дача может находиться в нескольких состояниях. Число и название этих состояний различаются от одной ОС к другой. Повидимому, наибольшее число состояний задачи определено в языке Ada. Тем не менее практически в любой ОС РВ загруженная на выпол- нение задача может находиться, по крайней мере, в трех состояниях. 1. Активная задача — это задача, выпол- няемая системой в текущей момент времени. 2. Готовая задача — это задача, готовая к выполнению и ожидающая у пла- нировщика своей «очереди». 3. Блокированная задача — это задача, выполнение которой приостанов- лено до наступления определенных событий. Такими событиями могут быть освобождение необходимого задаче ресурса, поступление ожида- емого сообщения, завершение ин- тервала ожидания и т. п. Пустая задача (Idle Task) — это за- дача, запускаемая самой операцион- ной системой в момент инициализа- ции и выполняемая только тогда, когда в системе нет других готовых для вы- полнения задач. Пустая задача запуска- ется с самым низким приоритетом и, как правило, представляет собой бес- конечный цикл «ничего не делать». На- личие пустой задачи предоставляет операционной системе удобный меха- низм отработки ситуаций, когда нет ни одной готовой к выполнению задачи. Многократный запуск задач . Как правило, многозадачные ОС позволя- ют запускать несколько копий одной и той же задачи. При этом для каждой такой копии создается свой ТСВ и вы- деляется своя область памяти. В целях экономии памяти может быть предус- мотрено совместное использование одного и того же исполняемого кода для всех запущенных копий. В этом случае программа должна обеспечи- вать повторную входимость (реенте- рабельность). Кроме того, программа не должна использовать временные файлы с фиксированными именами и должна корректно осуществлять до- ступ к глобальным ресурсам. Реентерабельность (повторная входимость) означает возможность без негативных последствий временно пре- рвать выполнение какойлибо функции или подпрограммы, а затем вызвать эту функцию или подпрограмму снова. Частным проявлением реентерабель- ности является рекурсия, когда тело подпрограммы содержит вызов самой себя. Классическим примером нереен- терабельной системы является DOS, а типичной причиной нереентерабель- ности служит использование глобаль- ных переменных. Предположим, что у нас есть функция, реализующая низко- уровневую запись на диск, и пусть она использует глобальную переменную write_sector, которая устанавливается в соответствии с параметром, передавае- мым этой функции при вызове. Пред- положим теперь, что Задача А вызывает эту функцию с параметром 3, то есть хо- чет записать данные в сектор номер 3. Допустим, что когда переменная wri- te_sector уже равна 3, но сама запись еще не произведена, выполнение Зада- чи А прерывается и начинает выпол- няться Задача В, которая вызывает ту же функцию, но с аргументом 10. После того как запись в сектор номер 10 бу- дет произведена, управление рано или поздно вернется к Задаче А, которая продолжит работу с того же места. Од- нако, так как переменная write_sector имеет теперь значение 10, данные За- дачи А, предназначавшиеся для сектора номер 3, будут вместо этого записаны в ОБЗОР Программное обеспечение 2/97 24