Термини: Вход-изход на данни синхронен и асинхронен. Синхронен и асинхронен I/O Синхронен и асинхронен I/O
Както знаете, има два основни режима на вход/изход: режим на обмен с запитване за готовност на I/O устройство и режим на обмен с прекъсвания.
В режим на обмен с анкета за готовност I / O се управлява от централния процесор. Централният процесор изпраща команда до управляващото устройство за извършване на някакво действие върху I/O устройството. Последният изпълнява командата, превеждайки сигнали, разбираеми за централното устройство и управляващото устройство, в сигнали, разбираеми за входно-изходното устройство. Но скоростта на I/O устройството е много по-малка от скоростта на процесора. Поради това трябва да чакате много дълго време за сигнала за готовност, като постоянно проверявате съответната интерфейсна линия за наличие или отсъствие на желания сигнал. Изпращането на нова команда без изчакване на сигнала за готовност, показващ изпълнението на предишната команда, е безсмислено. В режим на запитване за готовност драйверът, който управлява процеса на обмен на данни с външно устройство, просто изпълнява командата „проверка за сигнал за готовност“ в цикъл. Докато не се появи сигналът за готовност, водачът не прави нищо друго. В този случай, разбира се, времето на централния процесор се използва нерационално. Много по-изгодно е да подадете I/O команда, да забравите за I/O устройството за известно време и да преминете към друга програма. И появата на сигнал за готовност се интерпретира като заявка за прекъсване от I / O устройството. Именно тези сигнали за готовност са сигнали за заявка за прекъсване.
Режимът на обмен на прекъсвания по своята същност е асинхронен режим на управление. За да не се загуби връзката с устройството, може да се стартира обратно броене, по време на което устройството трябва задължително да изпълни командата и да издаде сигнал за искане за прекъсване. Максималният период от време, през който едно I/O устройство или неговият контролер трябва да издаде сигнал за искане за прекъсване, често се нарича законов изчакване. Ако това време е изтекло след подаване на следващата команда към устройството и устройството не е отговорило, тогава се прави извод, че връзката с устройството е прекъсната и вече не е възможно да се контролира. Потребителят и/или задачата получават съответното диагностично съобщение.
Ориз. 4.1. I/O контрол
Шофьори. работещи в режим на прекъсване, са сложен набор от софтуерни модули и могат да имат няколко секции: начална секция, една или повече продължаващи секции и крайна секция.
Стартовият раздел инициира I/O операция. Този раздел се изпълнява, за да включи I/O устройство или просто да инициира друга I/O операция.
Секция за продължение (може да има повече от една, ако алгоритъмът за контрол на комуникацията е сложен и са необходими множество прекъсвания за завършване на едно логическа операция) изпълнява основната работа по предаване на данни. Секцията за продължаване всъщност е главният манипулатор на прекъсванията. Използваният интерфейс може да изисква няколко последователности от контролни команди за управление на I / O, а сигналът за прекъсване за устройството по правило е само един. Следователно, след изпълнение на следващата секция за прекъсване, надзорникът на прекъсванията трябва да прехвърли управлението на друга секция при следващия сигнал за готовност. Това става чрез промяна на адреса за обработка на прекъсване след изпълнението на следващата секция, но ако има само една секция за прекъсване, тогава тя сама прехвърля управлението на един или друг обработващ модул.
Секцията за завършване обикновено изключва I/O устройството или просто прекратява операцията.
Входно-изходна операция може да бъде извършена на програмния модул, който е поискал операцията, синхронно или асинхронно. Значението на тези режими е същото като тези, разгледани по-горе. системни повиквания, - синхронен режим означава, че програмният модул спира работата си, докато I / O операцията приключи, а в асинхронен режим програмният модул продължава да се изпълнява в многопрограмен режим едновременно с I / O операцията. Разликата се състои във факта, че I / O операцията може да бъде инициирана не само от потребителския процес - в този случай операцията се извършва като част от системно повикване, но и от код на ядрото, например код на подсистема виртуална паметза четене на страница от паметта.
Ориз. 7.1. Два режима на извършване на I/O операции
Входно-изходната подсистема трябва да предостави на своите клиенти (потребителски процеси и код на ядрото) способността да извършват както синхронни, така и асинхронни входно-изходни операции, в зависимост от нуждите на повикващия. I/O системните повиквания често се оформят като синхронни процедури поради факта, че такива операции отнемат много време и потребителският процес или нишка все пак ще трябва да изчака резултатите от операцията, за да продължи работата си. Вътрешните I/O извиквания от модулите на ядрото обикновено се извършват като асинхронни процедури, тъй като кодът на ядрото се нуждае от свобода да избира какво да прави след I/O заявка. Използването на асинхронни процедури води до по-гъвкави решения, тъй като на базата на асинхронно повикване винаги е възможно да се изгради синхронно, като се създаде допълнителна междинна процедура, която блокира изпълнението на извикващата процедура до завършване на I/O. Понякога приложен процес също трябва да извърши асинхронна I/O операция, например в микроядрена архитектура, когато част от кода се изпълнява в потребителски режим като приложен процес, но изпълнява функции операционна система, изискваща пълна свобода на действие и след извикване на I/O операция.
IN компютърни системипод синхронен входИ синхронен изходразбират процесите на вход-изход на извадки от данни, при които интервалите от време (периодичност) на предаване на извадките към входа или изхода са изрично запазени. Входно-изходният синхрон се осигурява от някакъв вид хардуерна поддръжка (таймери и различни други периферни устройства със средства за синхронизация и използване на буфериране на данни за изравняване на входно-изходния поток от данни). В същото време терминът синхронен I/Oне означава непременно наличието на тактов сигнал на I/O интерфейса, а синхронизмът може да бъде осигурен както чрез вътрешна, така и чрез външна синхронизация.
Обикновено в процесорните и измервателните системи посоката на потока от данни (към вход или изход) се разглежда спрямо компютъра (процесора), който е в центъра на разглежданата архитектура. По-специално, преброяването на ADC и цифровите (дискретни) входове се считат за входни данни, а преброяването на DAC и цифровите (контролни) изходи се считат за изходни данни.
При асинхронен вход и изходвремевите интервали (периодичност) на предаване на показанията към входа или изхода не се запазват. В същото време данните влизат на входа или изхода със скоростта на самия интерфейс за пренос на данни, с непредсказуеми забавяния на буферирането, без да се запазват никакви времеви интервали. По-специално това означава за програмиста, че когато се използват асинхронни I/O функции, е безсмислено да се сравняват моментите на извикване на асинхронната I/O функция с физическите моменти на изпълнение на тази операция „от другата страна на интерфейса ” (подобно сравнение има смисъл само при статистически метод за обработка на данни) . Фактът, че е извършена асинхронна операция на изхода, може да бъде проверен с потвърждение (ако тази операцияизходът има потвърждение или потвърждението може да бъде получено чрез последваща операция за въвеждане на данни). С асинхронен I/O, горното буфериране на данниможе да играе противоположна роля и да увеличи несигурността на времето за доставка на данни при липса на механизъм за синхронизация и контрол на трафика на данни.
ADC/DAC модул
16/32 канала, 16 бита, 2 MHz, USB, Ethernet
Чакахме го твърде дълго
Какво по-тъпо от чакането?
Б. Гребенщиков
По време на тази лекция ще научите
Използване на системното повикване за избор
Използване на системното повикване за анкети
Някои аспекти на използването на select/poll в многонишкови програми
Стандартен асинхронен I/O
изберете системно повикване
Ако вашата програма е предимно I/O, можете да получите най-важните предимства на многопоточността в еднонишкова програма, като използвате системното извикване select(3C). В повечето Unix системи select е системно повикване или поне е описано в раздел 2 на системното ръководство (системни повиквания), т.е. тя трябва да бъде спомената като select(2), но в Solaris 10 съответната системна страница с ръководство е в раздел 3C (стандартната библиотека на C).
Входно-изходните устройства обикновено са много по-бавни от процесора, така че процесорът обикновено трябва да ги изчака, за да извършат операции върху тях. Следователно във всички операционни системи синхронните I/O системни повиквания блокират операциите.
Това важи и за мрежовите комуникации - взаимодействието през Интернет е свързано с големи закъснения и като правило се осъществява чрез не много широк и / или претоварен комуникационен канал.
Ако вашата програма работи с множество I/O устройства и/или мрежови връзки, за нея не е изгодно да блокира операция, свързана с едно от тези устройства, тъй като в това състояние може да пропусне възможността да извърши I/O от друго устройство без блокиране. Този проблем може да бъде разрешен чрез създаване на нишки, които работят с различни устройства. В предишни лекции научихме всичко необходимо за разработване на такива програми. Има обаче и други средства за решаване на този проблем.
Системното повикване select(3C) ви позволява да изчакате няколко устройства да бъдат готови, или интернет връзка(всъщност, готовността на обекти от повечето типове, които могат да бъдат идентифицирани чрез файлов дескриптор). Когато един или повече от дескрипторите са готови за изпращане на данни, select(3C) връща контрола на програмата и предава списъци с готови дескриптори в изходните параметри.
Select(3C) използва набори (набори) от дескриптори като параметри. В по-старите Unix системи наборите бяха реализирани като 1024-битови битови маски. В съвременните Unix системи и в други операционни системи, които прилагат select, наборите се изпълняват като непрозрачен тип fd_set, върху който са дефинирани някои теоретични операции, а именно изчистване на набор, включително дескриптор в набор, изключване на дескриптор от набор и проверка дали дескрипторът е в набор. Директивите на препроцесора за извършване на тези операции са описани в страницата с ръководство за select(3C).
На 32-битови версии на UnixSVR4, включително Solaris, fd_set все още е 1024-битова маска; в 64-битовите версии на SVR4 това е 65536-битова маска. Размерът на маската определя не само максималния брой файлови дескриптори в набора, но и максималния брой файлови дескриптори в набора. Размерът на маската във вашата версия на системата може да бъде определен по време на компилиране чрез стойността на символа на предпроцесора FD_SETSIZE. Номерирането на файловия дескриптор на Unix започва от 0, така че максималният номер на дескриптора е FD_SETSIZE-1.
Следователно, ако използвате select(3C), трябва да зададете ограничения за броя манипулатори на вашия процес. Това може да се направи с командата ulimit(1) на обвивката преди стартирането на процеса или със системното извикване setrlimit(2), докато вашият процес вече работи. Разбира се, setrlimit(2) трябва да бъде извикан преди да започнете да създавате файлови дескриптори.
Ако трябва да използвате повече от 1024 манипулатора в 32-битова програма, Solaris10 предоставя преходен API. За да го използвате, трябва да дефинирате
символ на препроцесора FD_SETSIZE с числова стойност, по-голяма от 1024, преди да включите файла
В някои реализации fd_set се реализира по други начини, без използването на битови маски. Например Win32 предоставя select като част от така наречения WinsockAPI. В Win32 fd_set се реализира като динамичен масив, съдържащ стойности на файлов дескриптор. Следователно не трябва да разчитате на познаването на вътрешната структура на типа fd_set.
Така или иначе, промяната на размера на битовата маска fd_set или вътрешното представяне на този тип изисква повторно компилиране на всички програми, използващи select(3C). В бъдеще, когато архитектурното ограничение от 65536 дескриптора на процес бъде увеличено, може да се наложи нова версия на изпълнението на fd_set и select и ново компилиране на програми. За да избегнете това и да улесните мигрирането към новата версия на ABI, SunMicrosystems препоръчва да отхвърлите select(3C) и вместо това да използвате системното извикване poll(2). Системното извикване poll(2) се обсъжда по-късно в тази глава.
Системното извикване select(3C) има пет параметъра.
intnfds е номер едно по-голям от максималния номер на файловия дескриптор във всички набори, предадени като параметри.
fd_set*readfds - входен параметър, набор от дескриптори, които трябва да бъдат проверени за четливост. Краят на файла или затварянето на сокета се счита за специален случай на готовност за четене. Обикновените файлове винаги се считат за готови за четене. Освен това, ако искате да проверите дали слушащ TCP сокет е готов да приеме (3SOCKET), той трябва да бъде включен в този набор. Освен това изходният параметър е набор от дескриптори, готови за четене.
fd_set*writefds - входен параметър, набор от дескриптори, които трябва да бъдат проверени за готовност за запис. Грешка при забавен запис се счита за специален случай на готовност за запис. Обикновените файлове винаги са готови за запис. Освен това, ако искате да тествате завършването на операция за асинхронно свързване (3SOCKET), сокетът трябва да бъде включен в този набор. Освен това изходният параметър е набор от дескриптори, готови за писане.
fd_set*errorfds – входен параметър, набор от дескриптори за проверка за изключения. Дефиницията на изключение зависи от типа на файловия дескриптор. За TCP сокети възниква изключение, когато пристигнат данни извън обхвата. Обикновените файлове винаги се считат за изключително състояние. Освен това изходният параметър е наборът от дескриптори, на които са възникнали изключителни условия.
structtimeval*timeout – изчакване, времеви интервал, определен с микросекунда точност. Ако този параметър е NULL, тогава select(3C) ще чака за неопределено време; ако структурата има интервал от време нула, select(3C) работи в режим на запитване, т.е. незабавно връща управление, вероятно с празни набори от дескриптори.
Вместо всички параметри на типа fd_set*, можете да подадете нулев указател. Това означава, че не се интересуваме от съответния клас на събитие. select(3C) връща общия брой готови дескриптори във всички комплекти при нормално завършване (включително завършване на изчакване) и -1 при грешка.
Пример 1 използва select(3C) за копиране на данни от мрежова връзка към терминал и от терминал към мрежова връзка. Тази програма е опростена, предполага, че писането в терминала и мрежовата връзка никога няма да бъдат блокирани. Тъй като и терминалът, и мрежовата връзка имат вътрешни буфери, това обикновено е така за малки потоци от данни.
Пример 1: Двустранно копиране на данни между терминал и мрежова връзка. Примерът е взет от W.R. Стивънс, Unix: Разработка мрежови приложения. Вместо стандартни системни извиквания се използват "обвивки", описани във файла "unp.h"
#include "unp.h"
void str_cli(ФАЙЛ *fp, int sockfd) (
int maxfdp1, stdineof;
char sendline, recvline;
if (stdineof == 0) FD_SET(fileno(fp), &rset);
FD_SET(sockfd, &rset);
maxfdp1 = max(fileno(fp), sockfd) + 1;
Изберете (maxfdp1, &rset, NULL, NULL, NULL);
if (FD_ISSET(sockfd, &rset)) ( /* сокетът е четим */
if (Readline(sockfd, recvline, MAXLINE) == 0) (
if (stdineof == 1) връщане; /* нормално прекратяване */
else err_quit("str_cli: сървърът е прекратен преждевременно");
Fputs(recvline, stdout);
if (FD_ISSET(fileno(fp), &rset)) ( /* входът е четим */
if (Fgets(sendline, MAXLINE, fp) == NULL) (
Изключване (sockfd, SHUT_WR); /* изпрати FIN */
FD_CLR(fileno(fp), &rset);
Write(sockfd, sendline, strlen(sendline));
Имайте предвид, че програмата от пример 1 пресъздава наборите дескриптори преди всяко извикване на select(3C). Това е необходимо, защото select(3C) променя опциите си, когато излезе нормално.
select(3C) се счита за MT-Safe, но когато го използвате в многонишкова програма, трябва да имате предвид следното. Всъщност select(3C) сам по себе си не използва локални данни и следователно извикването му от множество нишки не трябва да води до проблеми. Въпреки това, ако множество нишки работят върху припокриващи се набори от файлови дескриптори, е възможен следният сценарий:
Нишка 1 извиква четене от манипулатор s и получава всички данни от своя буфер
Нишка 2 извиква четене от манипулатори и блокове.
За да се избегне този сценарий, обработката на файлови дескриптори при такива условия трябва да бъде защитена от mutexes или някои други mutex примитиви. Важно е да се подчертае, че не изборът трябва да бъде защитен, а по-скоро последователността от операции върху конкретен файлов дескриптор, като се започне с включването на дескриптора в набора за избор и се стигне до получаване на данни от този дескриптор, по-точно, актуализиране на указателите в буфера, в който четете тези данни. Ако това не бъде направено, са възможни още по-вълнуващи сценарии, например:
Нишка 1 включва манипулатора s в набора readfds и извиква select.
изберете в нишка 1 връща s като готов за четене
Нишка 2 включва манипулатора s в набора readfds и извиква select
изберете в нишка 2 връща s като готов за четене
Нишка 1 извиква четене от дескриптор s и получава само част от данните от своя буфер
Нишка 2 извиква четене от дескриптора s, получава данните и презаписва данните, получени от нишка 1
В Лекция 10 ще разгледаме архитектурата на приложение, в което множество нишки споделят общ набор от файлови дескриптори - така наречената архитектура на работните нишки. В този случай нишките, разбира се, трябва да указват една на друга с кои дескриптори работят в момента.
От гледна точка на разработка на многонишкова програма, важен недостатък на select(3C) - или може би недостатък на POSIXThreadAPI - е фактът, че примитивите за синхронизиране на POSIX не са файлови дескриптори и не могат да се използват в select(3C). В същото време, при действителното разработване на многонишкови I/O програми, често би било полезно да се изчака в една операция файловите дескриптори да бъдат готови и другите нишки на собствения процес да бъдат готови.
синхронен моделвход изход. Системните извиквания read(2), write(2) и техните еквиваленти връщат контрол само след като данните са били прочетени или записани. Често това води до блокиране на нишката.Забележка
Всъщност не всичко е толкова просто. read(2) наистина трябва да изчака данните да бъдат физически прочетени от устройството, но write(2) работи в режим на обратно записване по подразбиране: той се връща, след като данните са прехвърлени в системния буфер, но обикновено преди данните да бъдат физически прехвърлени на устройството. Това като цяло подобрява значително наблюдаваната производителност на програмата и позволява паметта с данни да се използва за други цели веднага след връщане на write(2). Но мързеливото писане има и значителни недостатъци. Основният е, че няма да разберете резултата от физическа операция веднага по кода за връщане на write(2) , а само известно време след връщането, обикновено по кода за връщане на следващото извикване на write(2) . За някои приложения - за монитори на транзакции, за много програми в реално време и т.н. - това е неприемливо и те са принудени да изключат мързеливото писане. Това се прави с флага O_SYNC, който може да бъде зададен, когато файлът се отваря и променя от отворете файлачрез извикване на fcntl(2) .
Синхронизирането на отделните операции за запис може да се осигури чрез извикване на fsync(2) . За много приложения, които работят с множество устройства и/или мрежови връзки синхронен моделнеудобно. Работата в режим на анкета също не винаги е приемлива. Това е така, защото select(3C) и poll(2) считат файлов дескриптор за готов за четене само след като данните са се появили физически в неговия буфер. Но някои устройства започват да дават данни само след като бъдат изрично помолени да го направят.
Също така, за някои приложения, особено за приложения в реално време, е важно да знаете точния момент, когато данните започват да пристигат. За такива приложения може също да е неприемливо, че select(3C) и poll(2) вземат предвид редовни файловевинаги готов за четене и писане. Наистина ли, файлова системасе чете от диска и въпреки че е много по-бърз от повечето мрежови връзки, достъпът до него все още е свързан с известно забавяне. За твърди приложения в реално време тези забавяния може да не са приемливи - но без изрична заявка за четене файлова системане дава данни!
От гледна точка на твърди приложения в реално време, друг аспект на I/O проблема може да бъде важен. Факт е, че твърдите приложения в реално време имат по-висок приоритет от ядрото, така че изпълняват системни повиквания - дори и неблокиращи! - може да доведе до инверсия на приоритета.
Решението на тези проблеми е известно отдавна и се нарича асинхронен вход/ заключение . В този режим входно/изходните системни повиквания се връщат веднага щом бъде направена заявка към драйвера на устройството, обикновено дори преди данните да бъдат копирани в системния буфер. Формирането на заявка се състои в поставяне на запис ( IRP , Input/Output Request Packet , входно/изходен пакет заявка ) в опашката. За да направите това, просто трябва да заснемете за кратко мютекса, който защитава "опашката" на опашката, така че проблемът с инверсията на приоритета се преодолява лесно. За да разберете дали обаждането е приключило и ако е приключило, как точно и дали е възможно да се използва паметта, в която са били съхранени данните, е предоставен специален API (виж Фиг. 8.1)
Ориз. 8.1.
Асинхронен моделбеше основният I/O модел в OS като DEC RT-11, DEC RSX-11, VAX/VMS, OpenVMS. Почти всички подкрепят този модел под една или друга форма. ОС в реално време. От края на 80-те години Unix системите използват няколко несъвместими API за асинхронен I/O. През 1993 г. ANSI/IEEE прие POSIX 1003.1b, който описва стандартизиран API, който ще разгледаме по-късно в този раздел.
В Solaris 10 асинхронните I/O функции са включени в библиотеката libaio.so. За да създадете програми, които използват тези функции, трябва да използвате ключа -laio. Функциите aio_read(3AIO), aio_write(3AIO) и lio_listio(3AIO) се използват за генериране на заявки за асинхронен I/O.
Функциите aio_read(3AIO) и aio_write(3AIO) имат един параметър, structaiocb *aiocbp. aiocb структура, дефинирана във файл< aio .h>и съдържа следните полета:
- int aio_fildes - файлов дескриптор
- off_t aio_offset - отместване във файла, от който да се пише или чете
- volatile void* aio_buf - буфер за четене на данни от или за запис на данни.
- size_t aio_nbytes - размер на буфера. Подобно на традиционното read(2), aio_read(3AIO) може да прочете по-малко данни от заявените, но никога повече.
- int aio_reqprio - приоритет на заявката
- struct sigevent aio_sigevent - начин за сигнализиране на завършване на заявка (обсъдено по-късно в този раздел)
- int aio_lio_opcode - не се използва за aio_read(3AIO) и aio_write(3AIO), използва се само от функцията lio_listio.
Функцията lio_listio(3AIO) ви позволява да генерирате множество I/O заявки с едно системно извикване. Тази функция има четири параметъра:
- режим int - може да приема стойностите LIO_WAIT (функцията изчаква завършването на всички заявки) и LIO_NOWAIT (функцията връща контрола веднага след формирането на всички заявки).
- struct aiocb *list - списък с указатели към aiocb структури с описания на заявките.
Заявките могат да се четат и записват, това се определя от полето aio_lio_opcode. Заявките за единичен дескриптор се изпълняват в реда, в който са посочени в масива от списък.
- int nent - броят на записите в масива от списък.
- struct sigevent *sig - начин за сигнализиране на изпълнението на всички заявки. Ако mode==LIO_WAIT, този параметър се игнорира.
Библиотеката POSIX AIO предоставя два начина за уведомяване на програма, че дадена заявка е завършена, синхронен и асинхронен. Нека първо да разгледаме синхронния метод. Функцията aio_return(3AIO) връща статуса на заявка. Ако заявката вече е завършена и е завършена успешно, тя връща размера на прочетените или записани данни в байтове. Подобно на традиционното read(2), aio_return(3AIO) връща 0 байта в края на файла. Ако заявката е неуспешна или все още не е завършена, се връща -1 и се задава errno. Ако заявката все още не е завършена, кодът на грешката е EINPROGRESS.
aio_return(3AIO) е разрушителен; ако бъде извикан при завършена заявка, той ще унищожи системния обект, който съдържа информация за състоянието на заявката. Следователно извикването на aio_return(3AIO) няколко пъти за една и съща заявка не е възможно.
Функцията aio_error(3AIO) връща кода на грешка, свързан със заявката. Връща 0, ако заявката е успешна, код за грешка, ако е неуспешна, или EINPROGRESS за непълни заявки.
Функцията aio_suspend(3AIO) блокира нишка, докато една от посочените асинхронни I/O заявки не завърши или за определен период от време. Тази функция има три параметъра:
- const struct aiocb *const списък- масив от указатели към заявени дескриптори.
- int nent - броят на елементите в списъка масив.
- const struct timespec *изчакване- таймаут с точност до наносекунди (всъщност с точност до резолюция системен таймер).
Функцията връща 0, ако поне една от операциите, изброени в списъка, е завършена. Ако функцията се провали, тя връща -1 и задава errno. Ако времето за изчакване на функцията изтече, тя също връща -1 и errno==EINPROGRESS.
Пример за използване на асинхронен I/O със синхронна проверка на състоянието на заявка е показан в Пример 8.3.
Const char req="GET / HTTP/1.0\r\n\r\n"; int main() ( int s; static struct aiocb readrq; static const struct aiocb *readrqv=(&readrq, NULL); /* Отворен сокет […] */ memset(&readrq, 0, sizeof readrq); readrq.aio_fildes=s ; readrq.aio_buf=buf; readrq.aio_nbytes=sizeof buf; if (aio_read(&readrq)) ( /* ... */) write(s, req, (sizeof req)-1); while(1) ( aio_suspend (readrqv, 1, NULL); size=aio_return(&readrq); if (size>0) ( write(1, buf, size); aio_read(&readrq); ) else if (size==0) ( break; ) else if ( errno!=EINPROGRESS) ( perror("четене от сокет"); ) ) ) 8.3. Асинхронен I/O с проверка на статуса на синхронна заявка. Кодът е съкратен, отварянето на сокета и обработката на грешки са изключени от него.
Асинхронното уведомяване на приложението за завършване на операциите се състои в генериране на сигналв края на операцията. За да направите това, трябва да направите съответните настройки в полето aio_sigevent на дескриптора на заявката. Полето aio_sigevent е от тип struct sigevent. Тази структура е дефинирана в
- int sigev_notify - режим на уведомяване. Валидни стойности са SIGEV_NONE (не изпращайте потвърждения), SIGEV_SIGNAL (генерирайте сигнал, когато заявката завърши) и SIGEV_THREAD (изпълнете посочената функция в отделна нишка, когато заявката завърши). Solaris 10 също поддържа типа предупреждение SIGEV_PORT, който е разгледан в приложението към тази глава.
- int sigev_signo е номерът на сигнала, който ще бъде генериран при използване на SIGEV_SIGNAL.
- union sigval sigev_value е параметърът, който трябва да бъде предаден на манипулатора на сигнала или функцията на манипулатора. Когато се използва за асинхронен I/O, това обикновено е указател към заявка.
Когато използвате SIGEV_PORT, това трябва да е указател към структура port_event_t, съдържаща номера на порта и евентуално допълнителни данни.
- void (*sigev_notify_function)(union sigval)- функцията, която ще бъде извикана при използване на SIGEV_THREAD.
- pthread_attr_t *sigev_notify_attributes- атрибути на нишката, в която ще се стартира
- sigev_notify_function при използване на SIGEV_THREAD.
Не всички реализации на libaio поддържат известието SIGEV_THREAD. Някои Unix системи използват вместо това нестандартното известие SIGEV_CALLBACK. По-късно в тази глава ще обсъдим само предупреждение със сигнал.
Някои приложения използват или SIGIO, или SIGPOLL като номер на сигнала (те са един и същ сигнал на Unix SVR4). Често се използват и SIGUSR1 или SIGUSR2; това е удобно, защото гарантира, че подобен сигнал няма да се появи по друга причина.
Приложенията в реално време също използват числа на сигнала в диапазона SIGRTMIN до SIGRTMAX. Някои реализации разпределят специален номер на сигнала SIGAIO или SIGASYNCIO за тази цел, но няма такъв сигнал в Solaris 10.
Разбира се, преди да изпълните асинхронни заявки с известие за сигнал, трябва да инсталирате манипулатор за този сигнал. За известяване трябва да използвате сигнали, обработени в режим SA_SIGINFO. Не е възможно да зададете такъв манипулатор чрез системните извиквания signal(2) и sigset(2), трябва да използвате sigaction(2). Инсталиране на манипулатори със сигакция
I/O управление.
блоково ориентираниустройства и байт-ориентиран
основна идея
ключпринципът е независимост на устройството
Обработка на прекъсвания,
Изглежда очевидно, че са възможни голямо разнообразие от прекъсвания поради голямо разнообразие от причини. Следователно едно число е свързано с прекъсване - така нареченото число на прекъсване.
Този номер уникално съответства на определено събитие. Системата е в състояние да разпознае прекъсванията и, когато възникнат, стартира процедурата, съответстваща на номера на прекъсването.
Някои прекъсвания (първите пет в числов ред) са запазени за използване от процесора в случай на някакви специални събития като опит за деление на нула, препълване и т.н. (това всъщност са J вътрешни прекъсвания).
Хардуерните прекъсвания винаги възникват асинхронно по отношение на изпълняваните програми. Освен това могат да възникнат няколко прекъсвания едновременно!
За да не се изгуби системата, когато решава кое прекъсване да обслужи първо, има специална приоритетна схема. На всяко прекъсване се присвоява собствен приоритет. Ако се появят няколко прекъсвания по едно и също време, системата приоритизира най-високия приоритет, като отлага останалите прекъсвания за известно време.
Приоритетната система е реализирана на два чипа Intel 8259 (или подобни). Всеки чип е контролер за прекъсване и обработва до осем приоритета. Чиповете могат да се комбинират (каскадно), за да се увеличи броят на нивата на приоритет в системата.
Нивата на приоритет се обозначават съкратено като IRQ0 - IRQ15.
24. Управление на вход / изход. Синхронен и асинхронен I/O.
Една от основните функции на ОС е да управлява всички входно-изходни устройства на компютъра. ОС трябва да изпраща команди към устройствата, да улавя прекъсвания и да обработва грешки; трябва също така да осигурява интерфейс между устройствата и останалата част от системата. За целите на разработката интерфейсът трябва да е еднакъв за всички типове устройства (независимост от устройството). Повече за I/O контролен въпрос 23.
Принципи на защита
Тъй като операционната система UNIX от самото си създаване е замислена като многопотребителска операционна система, проблемът с разрешаването на достъпа на различни потребители до файловете на файловата система винаги е бил актуален в нея. Под оторизация за достъп имаме предвид действията на системата, които разрешават или отказват достъп на даден потребител до даден файл, в зависимост от правата за достъп на потребителя и ограниченията за достъп, зададени за файла. Схемата за оторизация на достъп, използвана в операционната система UNIX, е толкова проста и удобна и в същото време толкова мощна, че се превърна в де факто стандарт на съвременните операционни системи (които не претендират да бъдат системи с многостепенна защита).
Защита на файлове
Както е обичайно в многопотребителска операционна система, UNIX поддържа единен механизъм за контролиране на достъпа до файлове и директории на файловата система. Всеки процес може да има достъп до определен файл, ако и само ако правата за достъп, описани с файла, съответстват на възможностите този процес.
Защитата на файловете от неоторизиран достъп в UNIX се основава на три факта. Първо, всеки процес, който създава файл (или директория), е свързан с някакъв системен уникален потребителски идентификатор (UID - Потребителски идентификатор), което в бъдеще може да се интерпретира като идентификатор на собственика на новосъздадения файл. Второ, всеки процес, който се опитва да получи достъп до файл, има двойка идентификатори, свързани с него, идентификатори на текущия потребител и група. Трето, всеки файл отговаря уникално на неговия дескриптор - i-node.
На последния факт си струва да се спрем по-подробно. Важно е да разберете, че имената на файловете и файловете като такива не са едно и също нещо. По-специално, когато има множество твърди връзки към един и същ файл, няколко имена на файлове всъщност представляват един и същ файл и са свързани с един и същи i-възел. Всеки i-node, използван във файловата система, винаги отговаря уникално на един и само един файл. I-node съдържа доста различна информация (по-голямата част от нея е достъпна за потребителите чрез системните извиквания stat и fstat) и сред тази информация има част, която позволява на файловата система да оцени правата за достъп на даден процес към даден файл в необходимия режим.
Основни принципизащитите са еднакви за всички съществуващи варианти на системата: Информацията за i-node включва UID и GID на текущия собственик на файла (веднага след създаването на файла, идентификаторите на текущия му собственик се задават на съответния активен идентификатор на процеса на създаване, но по-късно може да бъде променен от системните извиквания на chown и chgrp). Освен това в i-възела на файла се съхранява скала, която показва какво потребителят - неговият собственик може да прави с файла, какво потребителите, принадлежащи към същата потребителска група като собственика, могат да правят с файла и какво другите могат да правят с файловете потребители. Малки подробности за внедряването в различни вариантисистемите са различни.
28. Контрол на достъпа до файлове в Windows NT. Списъци с права за достъп.
Системата за контрол на достъпа в Windows NT се характеризира с висока степен на гъвкавост, която се постига чрез голямо разнообразие от субекти и обекти за достъп, както и детайлността на операциите за достъп.
Контрол на достъпа до файлове
За споделени ресурси в Windows NT, общ моделобект, който съдържа такива характеристики за сигурност като набор от разрешени операции, идентификатор на собственик, списък за контрол на достъпа.
Обектите в Windows NT се създават за всеки ресурс, в случай че те са или станат споделени - файлове, директории, устройства, секции на паметта, процеси. Характеристиките на обектите в Windows NT са разделени на две части - обща част, чийто състав не зависи от вида на обекта, и индивидуална част, определена от типа на обекта.
Всички обекти се съхраняват в дървовидни йерархични структури, чиито елементи са клонови обекти (директории) и листови обекти (файлове). За обектите на файловата система тази схема на връзка е пряко отражение на йерархията на директориите и файловете. За обекти от други типове схемата за йерархична връзка има собствено съдържание, например за процеси тя отразява отношенията родител-дете, а за устройствата отразява принадлежността към определен тип устройство и връзката на устройството с други устройства, например SCSI контролер с дискове.
Проверката на правата за достъп за обекти от всякакъв тип се извършва централно с помощта на Security Reference Monitor, който работи в привилегирован режим.
За система Защита на Windows NT се характеризира с наличието на голям брой различни предварително дефинирани (вградени) субекти за достъп - както отделни потребители, така и групи. Така че в системата винаги има потребители като Adininistrator, System и Guest, както и групи Users, Adiniiistrators, Account Operators, Server Operators, Everyone и други. Значението на тези вградени потребители и групи е, че те са надарени с някои права, което улеснява администратора да създаде ефективна система за контрол на достъпа. Когато добавя нов потребител, администраторът трябва само да реши към коя група или групи да присвои този потребител. Разбира се, администраторът може да създава нови групи, както и да добавя права към вградените групи, за да реализира собствена политика за сигурност, но в много случаи вградените групи са достатъчни.
Windows NT поддържа три класа операции за достъп, които се различават по вида на субектите и обектите, включени в тези операции.
□ Разрешенията са набор от операции, които могат да бъдат дефинирани за субекти от всякакъв тип по отношение на обекти от всякакъв тип: файлове, директории, принтери, секции на паметта и т.н. Разрешенията по своята цел съответстват на правата за достъп до файлове и директории в QC UNIX.
□ Права (потребителски права) - определят се за субекти от групов тип за извършване на някои системни операции: настройка на системното време, архивиране на файлове, изключване на компютъра и др. Тези операции включват специален обект за достъп - операционната система като цяло .
Основно правата, а не разрешенията, отличават една вградена потребителска група от друга. Някои права на вградена група също са вградени - те не могат да бъдат премахнати от тази група. Останалите права на вградената група могат да бъдат премахнати (или добавени от общия списък с права).
□ Потребителските способности са определени за отделните потребители да извършват действия, свързани с формирането на тяхната работна среда, например промяна на състава на главното меню на програмите, възможността за използване на елемента от менюто Run и т.н. Чрез намаляване на набора от възможности (които са достъпни за потребителя по подразбиране), администраторът може да принуди потребителя да работи с операционната среда, която администраторът счита за най-подходяща и предпазва потребителя от възможни грешки.
Правата и разрешенията, дадени на група, се предоставят автоматично на нейните членове, което позволява на администратора да преглежда голям бройпотребителите като единица счетоводна информация и минимизиране на техните действия.
Когато потребител влезе в системата, за него се създава така наречения токен за достъп, който включва потребителския идентификатор и идентификаторите на всички групи, към които принадлежи потребителят. Токенът също така съдържа: списък за контрол на достъпа по подразбиране (ACL), който се състои от разрешения и се прилага към обекти, създадени от процеса; списък с потребителски права за извършване на системни действия.
Всички обекти, включително файлове, потоци, събития, дори маркери за достъп, са снабдени с дескриптор за сигурност, когато са създадени. Дескрипторът за защита съдържа списък за контрол на достъпа - ACL.
Файлов дескрипторе неотрицателно цяло число, присвоено от ОС на файла, отворен от процеса.
ACL(Английски) Списък за контрол на достъпа- списък за контрол на достъпа, на английски се произнася "ekl") - определя кой или какво има достъп до определен обект и какви операции са разрешени или забранени за този субект да извършва върху обекта.
Списъците за контрол на достъп са гръбнакът на системите за селективен контрол на достъпа. ( Wiki)
Собственикът на обект, обикновено потребителят, който го е създал, има правото избирателно да контролира достъпа до обекта и може да промени ACL на обекта, за да разреши или забрани на други хора достъп до обекта. вградена Windows администратор NT, за разлика от суперпотребителя на UNIX, може да няма някои права за достъп до обект. За да се приложи тази функция, идентификаторите на администратори и идентификаторите на администраторските групи могат да бъдат включени в ACL, точно както обикновените потребителски идентификатори. Въпреки това, администраторът все още има възможността да извършва всякакви операции с всякакви обекти, тъй като той винаги може да стане собственик на обекта и след това, като собственик, да получи пълния набор от разрешения. Въпреки това администраторът не може да върне собствеността на предишния собственик на обекта, така че потребителят винаги може да разбере, че администраторът е работил с неговия файл или принтер.
Когато даден процес поиска операция за достъп до обект в Windows NT, контролът винаги се прехвърля към монитора за сигурност, който сравнява идентификаторите на потребителя и потребителската група от маркера за достъп с идентификаторите, съхранени в ACL елементите на обекта. За разлика от UNIX, ACL елементите на Windows NT могат да съдържат както списъци с разрешени операции, така и списъци със забранени операции за потребителя.
Windows NT изрично дефинира правилата, по които на новосъздадения обект се присвоява ACL. Ако извикващият код по време на създаването на обект изрично задава всички права за достъп до новосъздадения обект, тогава системата за сигурност присвоява този ACL на обекта.
Ако извикващият код не предоставя на обекта ACL, но обектът има име, тогава се прилага принципът на наследяване на разрешения. Системата за сигурност преглежда ACL на обектната директория, където се съхранява името на новия обект. Някои от ACL записите в обектната директория могат да бъдат маркирани като наследени. Това означава, че те могат да бъдат присвоени на нови обекти, създадени в тази директория.
В случай, че процесът не е задал изрично ACL за създавания обект и обектът на директорията няма наследени ACL елементи, се използва ACL по подразбиране от токена за достъп на процеса.
29. Език за програмиране Java. Java виртуална машина. Java технология.
Javaе обектно-ориентиран език за програмиране, разработен от Sun Microsystems. Java приложенията обикновено се компилират в специален байт код, така че могат да работят на всяка Java виртуална машина (JVM), независимо от компютърната архитектура. Програмите на Java се превеждат в изпълним файл с байт код виртуална машина java( JVM) - програма, която обработва байт код и предава инструкции към оборудването като интерпретатор, но с тази разлика, че байт кодът, за разлика от текста, се обработва много по-бързо.
Предимството на този начин на изпълнение на програми е пълната независимост на байт кода от операционната система и хардуера, което ви позволява да стартирате Java приложения на всяко устройство, за което има съответна виртуална машина. Друга важна характеристика на Java технологията е гъвкавата сигурност поради факта, че изпълнението на програмата се контролира изцяло от виртуалната машина. Всяка операция, която надхвърля зададените разрешения на програмата (като опит за неоторизиран достъп до данни или свързване с друг компютър), води до незабавно прекъсване.
Често недостатъците на концепцията за виртуална машина включват факта, че изпълнението на байт код от виртуална машина може да намали производителността на програмите и алгоритмите, реализирани на езика Java.
Java виртуална машина(съкратено Java VM, JVM) - виртуалната машина на Java - основната част от изпълнението Java системи, така нареченият Java RuntimeОколна среда (JRE). Виртуалната машина на Java интерпретира и изпълнява байт код на Java, генериран преди това от изходния код на програмата на Java от компилатора на Java (javac). JVM може да се използва и за изпълнение на програми, написани на други езици за програмиране. Например, източникНа език Адаможе да се компилира в Java байт код, който след това може да се изпълни от JVM.
JVM е ключов компонент на платформата Java. Тъй като Java виртуалните машини са налични за много хардуерни и софтуерни платформи, Java може да се разглежда и като мост софтуер, и като независима платформа, оттук и принципът "written once, run everywhere" (напиши веднъж, пусни навсякъде). Използването на един байт код за много платформи позволява Java да бъде описана като "компилирай веднъж, стартирай навсякъде" (компилирай веднъж, стартирай навсякъде).
Време за изпълнение
Програмите, предназначени да работят на JVM, трябва да бъдат компилирани в стандартизиран преносим двоичен формат, който обикновено се представя като .class файлове. Една програма може да се състои от много класове, поставени в различни файлове. За да се улесни хостването на големи програми, някои от .class файловете могат да бъдат пакетирани заедно в така наречения .jar файл (съкратено от Java Archive).
JVM изпълнява .class или .jar файлове, като емулира инструкции, написани за JVM чрез интерпретиране или използване на компилатор точно навреме (JIT), като HotSpot от Sun microsystems. Тези дни JIT компилацията се използва в повечето JVM, за да се постигне по-голяма скорост.
Подобно на повечето виртуални машини, Java Virtual Machine има ориентирана към стека архитектура, която е обща за микроконтролерите и микропроцесорите.
JVM, който е екземпляр на JRE (Java Runtime Environment), влиза в действие при изпълнение на Java програми. След завършване на изпълнението този екземпляр се премахва от събирача на отпадъци. JIT е част от Java Virtual Machine, която се използва за ускоряване на времето за изпълнение на приложенията. JIT едновременно компилира части от байт кода, които имат сходна функционалност и следователно намалява времето, необходимо за компилиране.
j2se (стандартно издание на Java 2) - Стандартната библиотека включва:
GUI, NET, база данни…
30. .NET платформа. Основни идеи и положения. Езици за програмиране .NET.
.NET Framework - софтуерна технология от Microsoft, предназначена за създаване редовни програмии уеб приложения.
Една от основните идеи на Microsoft .NET е съвместимостта на различни услуги, написани на различни езици. Например услуга, написана на C++ за Microsoft .NET, може да има достъп до метод на клас от библиотека, написана на Delphi; в C# можете да напишете клас, който наследява клас, написан в Visual Basic.NET и изключение, хвърлено от метод, написан на C#, може да бъде уловено и обработено в Delphi. Всяка библиотека (сглобка) в .NET има информация за нейната версия, което ви позволява да елиминирате възможните конфликти между различните версии на сглобките.
Приложенията могат да се разработват и в текстов редактори използвайте конзолния компилатор.
Подобно на технологията Java, средата за разработка на .NET създава байт код, който е предназначен да бъде изпълнен от виртуална машина. Входният език на тази машина в .NET се нарича MSIL (Microsoft Intermediate Language), или CIL (Common Intermediate Language, по-късно), или просто IL.
Използването на байт код ви позволява да получите крос-платформа на ниво компилиран проект (в термините на .NET: монтаж), а не само на ниво източник, както например в C. Преди да започне асемблирането в CLR runtime, байткодът се преобразува от JIT компилатора, вграден в средата (точно навреме, компилация в движение) в машинни кодове на целевия процесор. Също така е възможно да се компилира сборка в собствен код за избраната платформа с помощта на помощната програма NGen.exe, доставена с .NET Framework.
По време на процедурата за превод изходният код на програмата (написан на SML, C #, Visual Basic, C ++ или всеки друг език за програмиране, който се поддържа от .NET) се преобразува от компилатора в така нареченото асемблиране ( асемблиране) и записан като файл с динамично свързана библиотека (Dynamically Linked Library, DLL) или изпълним файл (Executable, EXE).
Естествено, за всеки компилатор (независимо дали е C# компилатор, csc.exe или Visual Basic, vbc.exe), средата за изпълнение извършва необходимото картографиране на използваните типове в CTS типове и програмния код в кода на " абстрактна машина" .NET - MSIL (междинен език на Microsoft).
В резултат на това софтуерният проект се формира като сборка - самодостатъчен компонент за внедряване, репликация и повторна употреба. Монтажът е идентифициран цифров подписавтор и уникален номер на версията.
Вградени езици за програмиране (доставени с .NET Framework):
° С#; J#; VB.NET JScript .NET C++/CLI- нова версия C++ (управляван).
31. Функционални компонентиОПЕРАЦИОННА СИСТЕМА. Управление на файлове
Функционални компоненти на ОС:
Функциите на операционната система на самостоятелен компютър обикновено се групират или според типовете локални ресурси, които операционната система управлява, или според конкретни задачи, които се прилагат за всички ресурси. Понякога такива групи от функции се наричат подсистеми. Най-важните подсистеми за управление на ресурсите са подсистемите за управление на процеси, памет, файлове и външни устройства, а подсистемите, общи за всички ресурси, са подсистемите потребителски интерфейс, защита на данните и администриране.
Управление на файлове:
Способността на ОС да "екранира" сложността на реалния хардуер се проявява много ясно в една от основните подсистеми на ОС - файловата система.
Файловата система свързва носител за съхранение от една страна и API (интерфейс за програмиране на приложения) за достъп до файлове от друга. Когато приложна програма има достъп до файл, тя няма представа как се намира информацията в даден файл, както и на какъв физически тип носител (CD, твърд диск, магнитна лента или флаш памет) е записана. Всичко, което програмата знае, е името на файла, неговия размер и атрибути. Той получава тези данни от драйвера на файловата система. Файловата система е тази, която определя къде и как ще бъде записан файлът на физически носител (например твърд диск).
От гледна точка на операционната система, целият диск е набор от клъстери от 512 байта и повече. Драйверите на файловата система организират клъстери във файлове и директории (които всъщност са файлове, съдържащи списък от файлове в тази директория). Същите драйвери следят кои клъстери се използват в момента, кои са свободни и кои са маркирани като неуспешни.
Файловата система обаче не е непременно директно свързана с физическия носител за съхранение. Има виртуални файлови системи, както и мрежови файлови системи, които са просто начин за достъп до файлове, които са на отдалечен компютър.
В най-простия случай всички файлове на този дисксе съхраняват в същата директория. Тази схема на едно ниво беше използвана в CP/M и в първата версия на MS-DOS 1.0. Йерархичната файлова система с вложени директории се появява за първи път в Multics, след това в UNIX.
Директориите на различни устройства могат да формират няколко отделни дървета, както в DOS/Windows, или могат да бъдат комбинирани в едно дърво, общо за всички устройства, както в UNIX-подобни системи.
Всъщност в системите DOS / Windows, както и в подобните на UNIX системи, има една главна директория с вложени директории, наречени „c:“, „d:“ и т.н. Дяловете на твърдия диск се монтират в тези директории. Тоест c:\ е просто връзка към file:///c:/. Въпреки това, за разлика от UNIX-подобните файлови системи, влизане в Windowsкъм основната директория е забранено, както и преглеждането на нейното съдържание.
В UNIX има само една основна директория и всички останали файлове и директории са вложени в нея. За да получите достъп до файлове и директории на устройство, трябва да монтирате това устройство с командата mount. Например, за да отворите файлове на компактдиск, трябва да кажете обикновен език, кажете на операционната система: "вземете файловата система на този компактдиск и я покажете в директорията /mnt/cdrom". Всички файлове и директории на компактдиска ще се появят в тази директория /mnt/cdrom, която се нарича точка на монтиране. В повечето UNIX-подобни системи сменяемите дискове (дискети и компактдискове), флаш памети и други външни устройства за съхранение се монтират в директорията /mnt, /mount или /media. Unix и UNIX-подобните операционни системи също ви позволяват автоматично да монтирате дискове, когато операционната система се зарежда.
Забележете използването на наклонени черти файлови системи Windows, UNIX и UNIX-подобни операционни системи (Windows използва обратна наклонена черта „\“, а UNIX и UNIX-подобни операционни системи – проста наклонена черта „/“)
Освен това трябва да се отбележи, че горната система ви позволява да монтирате не само файловите системи на физическите устройства, но и отделни директории (параметърът --bind) или, например, ISO изображение (опцията за цикъл). Добавки като FUSE също ви позволяват да монтирате, например, цяла директория на FTP и много голям брой различни ресурси.
Още по-сложна структура се използва в NTFS и HFS. В тези файлови системи всеки файл е набор от атрибути. Атрибутите се считат не само за традиционните само за четене, системата, но също така и името на файла, размера и дори съдържанието. По този начин, за NTFS и HFS, това, което се съхранява във файл, е само един от неговите атрибути.
Следвайки тази логика, един файл може да съдържа множество варианти на съдържание. Така в един файл могат да се съхраняват множество версии на един и същи документ, както и допълнителни данни (икона на файл, програма, свързана с файла). Тази организация е типична за HFS на Macintosh.
32. Функционални компоненти на ОС. Управление на процеси.
Управление на процесите:
Най-важната част от операционната система, която пряко влияе върху функционирането на компютъра, е подсистемата за управление на процесите. Процес (или с други думи, задача) е абстракция, която описва работеща програма. За операционната система процесът е единица работа, заявка за потребление на системни ресурси.
В многозадачна (мултипроцесна) система един процес може да бъде в едно от три основни състояния:
ИЗПЪЛНЕНИЕ - активното състояние на процеса, по време на което процесът разполага с всички необходими ресурси и се изпълнява директно от процесора;
ИЗЧАКВАНЕ - пасивно състояние на процеса, процесът е блокиран, не може да бъде изпълнен поради вътрешни причини, чака да се случи някакво събитие, например завършване на I / O операция, получаване на съобщение от друг процес , освобождавайки някакъв ресурс, от който се нуждае;
READY - също пасивно състояние на процеса, но в този случай процесът е блокиран поради външни за него обстоятелства: процесът разполага с всички необходими ресурси, готов е за изпълнение, но процесорът е зает с изпълнение на друг процес.
По време на жизнен цикълвсеки процес преминава от едно състояние в друго в съответствие с алгоритъма за планиране на процеса, внедрен в дадената операционна система.
CP/M стандарт
Началото на създаването на операционни системи за микрокомпютри беше положено от OS SR / M. Разработен е през 1974 г., след което е инсталиран на много 8-битови машини. В рамките на тази операционна система е създадено значително количество софтуер, включително преводачи от BASIC, Pascal, C, Fortran, Cobol, Lisp, Ada и много други, текст. Те ви позволяват да подготвяте документи много по-бързо и по-удобно, отколкото с пишеща машина.
MSX стандарт
Този стандарт определя не само операционната система, но и характеристиките на хардуера за училищни компютри. Според стандарта MSX машината трябваше да има RAMне по-малко от 16 K, памет само за четене 32 K с вграден езиков интерпретатор BASIC, цветен графичен дисплейс резолюция 256х192 пиксела и 16 цвята, триканален звуков генераторза 8 октави, паралелен порт за свързване на принтер и контролер за управление на външен диск, свързан външно.
Операционната система на такава машина трябваше да има следните свойства: необходима памет - не повече от 16 K, съвместимост с CP / M на ниво системни повиквания, съвместимост с DOS по отношение на файловите формати на външни дисковена базата на флопи дискове, поддръжка на BASIC, C, Fortran и Lisp преводачи.
Пи - система
В началния период на развитие персонални компютриСъздадена е операционната система USCD p-system. Основата на тази система беше така наречената P-машина - програма, която емулира хипотетичен универсален компютър. P-машината симулира работата на процесора, паметта и външните устройства чрез изпълнение на специални инструкции, наречени P-код. Софтуерни компоненти Pi-системите (включително компилаторите) се компилират в P-код, приложните програми също се компилират в P-код. Така основната отличителна черта на системата беше минималната зависимост от характеристиките на хардуера на компютъра. Това е, което гарантира преносимостта на Pi-системата към Различни видовемашини. Компактността на P-кода и удобно реализираният механизъм за страниране направиха възможно изпълнението на относително големи програми на компютър с малка RAM.
I/O управление.
I/O устройствата са разделени на два типа: блоково ориентираниустройства и байт-ориентиранустройства. Блоково ориентираните устройства съхраняват информация в блокове с фиксиран размер, всеки със собствен адрес. Най-разпространеното блоково ориентирано устройство е дискът. Байт-ориентираните устройства не са адресируеми и не позволяват операция за търсене, те генерират или консумират поредица от байтове. Примери за това са терминали, линейни принтери, мрежови адаптери. Електронен компонентнаречен контролер на устройство или адаптер. Операционната система се занимава с контролера. Контролерът изпълнява прости функции, следи и коригира грешки. Всеки контролер има няколко регистъра, които се използват за взаимодействие с централния процесор. ОС извършва I/O чрез записване на команди в регистрите на контролера. Контролер дискета IBM PC приема 15 команди като READ, WRITE, SEEK, FORMAT и др. Когато командата бъде получена, процесорът напуска контролера и върши друга работа. Когато командата приключи, контролерът организира прекъсване, за да прехвърли управлението на процесора към операционната система, която трябва да провери резултатите от операцията. Процесорът получава резултатите и състоянието на устройството чрез четене на информация от регистрите на контролера.
основна идея I/O софтуерна организациясе състои в разделянето му на няколко нива, като долните нива осигуряват скрининг на хардуерните характеристики от горните, а тези осигуряват удобен за потребителя интерфейсза потребители.
ключпринципът е независимост на устройството. Формата на програмата не трябва да зависи от това дали чете данни от дискета или от харддиск. Друг важен въпрос за I/O софтуера е обработката на грешки. Най-общо казано, грешките трябва да се обработват възможно най-близо до хардуера. Ако контролерът открие грешка при четене, той трябва да се опита да я коригира. Ако не успее, тогава драйверът на устройството трябва да коригира грешките. И само ако по-ниското ниво не може да се справи с грешката, то докладва грешката на по-горното ниво.
Друг ключов проблем е използването на блокиращи (синхронни) и неблокиращи (асинхронни) трансфери. Повечето физически входно-изходни операции са асинхронни - процесорът започва прехвърляне и преминава към друга задача, докато не настъпи прекъсване. I/O операциите трябва да са блокиращи - след командата READ, програмата автоматично се спира, докато данните влязат в програмния буфер.
Последният проблем е, че някои устройства са споделени (дискове: едновременният достъп на няколко потребители до диска не е проблем), докато други са предназначени (принтери: не можете да смесвате редове, отпечатани от различни потребители).
За да разрешите поставените проблеми, препоръчително е да разделите I / O софтуера на четири слоя (Фигура 2.30):
Обработка на прекъсвания,
драйвери на устройства,
Независим от устройството слой на операционната система,
· Персонализиран софтуерен слой.
Концепцията за хардуерно прекъсване и неговата обработка.
Асинхронни или външни (хардуерни) прекъсвания - събития, които идват от външни източници (напр. периферни устройства) и може да възникне във всеки произволен момент: сигнал от таймер, мрежова карта или дисково устройство, натискане на клавиши на клавиатурата, движение на мишката; Те изискват незабавен отговор (обработка).
Почти всички I/O системи в компютъра работят с помощта на прекъсвания. По-специално, когато натискате клавиши или щраквате с мишката, хардуерът генерира прекъсвания. В отговор на тях системата съответно чете кода на натиснатия клавиш или запомня координатите на курсора на мишката. Прекъсванията се генерират от дисковия контролер, адаптера локална мрежа, серийни портове, аудио адаптер и други устройства.