3.Средства от високо ниво.

3.1Езикова конструкциякритична секция.За да се избегнат грешките,зависещи от от времето Хоар и Хансен предлагат метода на Дейкстра да се формализира в термините на езиците от по-високо ниво.Променлива от зададен тип (може и да е сложна структура),която е достъпна в критични секции на няколко процеса, трябва да се декларира като делим ресурс. Предимството на този метод е, че транслаторът генерира за всяка консрукция region необходимите семафори:P(c_sem);оператор;V(c_sem),като за всяко описание на променливата с се генерира описание на семафора c_sem, инициализиран с 1.Освен това , по време на транслация се прави проверека, дали достъпът до общите променливи се прави в ктитични секции. Критичните секции могат да се влагат, но в този случай може да възникне мъртва хватка:Ако идвата процеса влизат едновременно в критичните секции,те ще изпаднат в мъртва хватка.Тази конструкция решава простите проблеми на критичните секции, но не може да се използва за по-общи схеми за сихронизация.Затова тя се разширява с условие.

3.2Условна критична секция.Дотук описаните средства задържахи процесите до изпълнението на определени условия(критичните секции-до освобождаване на критичните ресурси, семафорите-до получаване на сигнал, пощенската кутия-до получаване на съобщение). При взаимодействието на процесите може да възникне следният случай:процес изменя стойноста на променлива, друг процес чете новата стойност. Но, вторият процес не трябва да чете докато първият не даде нова стойност и обратното първият процес не трябва да дава нова стойност, докато вторият процес не прочете старата стойност.В този случай се прилага конструкцията-условна критична секция, която позволява на процеса да чака до изпълнението на произволно условие.Тя има вида: region име на променлива when условие do оператор; Синхронизиращото условие е булев израз, в който могат да влизат съставни на променливата. Стойноста на условието се проверява при влизане в критичната секция. Ако тя е true, операторът се изпълнява. В противен случай този вход в критичната секция се задържа, за да могат груги процеси да влязат в своите критични секции и евентуално да изменят общата променлива, оттук и някое условие. Затова всеки път, когато процес напусне критична секция, се дава възможност на всички блокирани процеси да проверят отново условията си.Ако изпълнено условието на няколко блокирани процеси, един от тях, ще влезне в критичната си секция.В противен случай процесите отново се блокират. Най-просто е решението с два семсфорс и FIFO-опашка.Тази конструкция позволява блокиране на процесите в началото на критичната секция, на в някои случаи се налага да се приложи друга форма на условната критична секция.Защото тя губи време и трудно се реализира.Когато процес влезе в критичната си секция, той може да бъде задържан от await, докато не се изпълни условието и няма друг процес в критичната секция.Тя действа като горепосочената и има вида:region име на променливата do begin await(условие); ; end;

3.3Монитори.

Мониторът може да включва декларации на константи, типове и локални процедури.Предполага се, че при пускане на програмата се изпълнява инициализиращата част на всички монитори.Всички променливи, декларирани в монитора, са локални, с изключение на процедурите entry (наричат се още мониторни процедури). Всяка процедура представлява операция над общите данни и може да се извиква извън монитора чрез идентификатор с форма: име на монитора.име на процедура. Забранена е рекусивността и взаимното извикване на мониторни процедури.Процедурите plpn също са критични секции-винаги може да бъде извикана само една процедура.Затова само един процес може да има в даден момент достъп до общите променливи.Обопщено:1.Мониторните процедури са единствените операции, които процесите могат да изпълняват над общите променливи. 2.Дефинираните в мониторите операции са взаимно изключени, така че процес, извиквайки мониторна процедура, влиза в критична секция. Сега критичните секции не са в процесите, а са обединени втялото на монитора. Допълнителният механизъм за синхронизация при мониторите се изразява в следното:въвежда се променливи тип условие (condition). При декларирането на тези променливи се организира опашка, в която се поместват блокираните процеси. Над тези променливи могат да се изпълняват две операции:wait-(име на условието) и signal(име на условието). Процес извикващ wait, се записва в опашката и се блокира, като дава възможност на други процеси да извикват мониторните процедури. Операцията signal, възобновява изпълнението на един блокиран процес, а вцлучай, че опашката е празна-няма никакъв ефект.Мониторът работи, ката двоичен семафор-при заемане на ресурси се изпълнява функцията Р, а при освобождаване функция V. За да се осигури споазването на съответната последователност от всички процеси, трябва да бъдат наблюдавани всички процеси, използващи монитора и ресурса. Има две условия, които трябва да се проверят, са да се установи коректността на системата.1-потребителските процеси трябва винаги да правят извикванията на монитора в коректна последователност.2-,трябва да е сигурно, че някакъв некоопериран процес няма да игнорира взаимното изключване, организирано от монитора и да се опита да вземе общия ресурс, без да използва протокола за достъп. Проблем е вложеното викане на монитори-ако монитор М1 вика монитор М2, взаимното изключване в М1 продължава, докато трае изпълнението в М2. Този факт има две следствия: 1.всеки процес, извикващ М1, ще бъде блокиран пред М1 през това време. 2.ако процес влезе в опашката на условие в М2, може да настъпи мъртва хватка. Реда на възобновяване на процесите може да бъде подобрен като се прилоги условно чакане от вида wait(х,с), където с е цял израз, който се изчислява при изпълнението на wait.Стойността на с ще представлява приоритетът, който се запомня заедно с името на блокираният процес. При изпълнението на signal(x) ще се възобнови процес с най-малка стойност на с. Недостатъкът на мониторите, че при използването им се централизира управлението, което стеснява класа от задачи,където може да се прилагат. Освен това използването им в разпределени системи и големи общи ресурси е сложно и трудно.3.3.1Пример:читатели и писатели. Алгоритъма се състои в следното има писатели читатели.В всеки момент, когато писател пише никой читател не може да чете. Когато читател иска да чете, той извиква процедурата начало на четене, а след като завърши работа процердурата край на четене.След влизане в начало на четене читател може да продължи, ако няма писател, извършващ в този момент запис или чакащ в опашка за запис.Второто изискване е необходимо, за да се избегне безкрайното отлагане на чакащи писатели. Процедурата завършва със сигнализиране четене-разрешено, за да може друг чакащ процес да започне четене. Следващият читател се активизира и също сигнализира на намиращият след него в опашката процес за възможността да продължи(когато се изпълни signal, мониторът не се освобождава за влизане на нови процеси, а в мониторът се активизира процес, блокиран при условието). Подобна верижна реакция продължава, докато не се активизират всички читатели. По време на изпълнението на веригата нови идващи процеси се включват в опашката на за чакане пред монитора. По време на на изпълнение на веригата на активизация дори новоприходящите читатели не могат да влязат в монитора-съгласно правилот, че процесите, получили вече сигнал за активизиране, се обслужват по-рано от новите процеси.След завършване на четенето(което не е безкрайно) се влиза в процедура край на четене-при което читатели=читатели-1.След многократно изпълнение читатели=0 и тогава се сигнализира писане разрешено.Когато получи възможност за работа, писателя прави някой пише=true , с което блокира останалите активирани писатели и читатели.Когато завърши работа, той извиква процедура край на запис,където се прави някой пише=folse и мониторът се открива за други процес.

3.4.Задачи и рандеву в АДА. Задачата task в Ада е програмен модул, който може да се изпълнява асихронно и да взаимодейства с други задачи(последователен процес). Има извикваща и обслужваща задача, за да се осигури взаимодействието е вграден механизъм наречен рандеву(взаимно изчакване). Извикващата програма се обръща към определен вход(entry) на обслужващата задача подобно на процедура с или без параметри. Опростено обръщение-име на задача.име на вход .Обслужващата задача за да приеме извикването, изпълнява специален оператор accept s форма accept имена вход[формални параметри][ do оператори {критична секция} end ] [име на вход]; Ако при изпращането на заявка към обслужващата задача, последната още не издала команда accept,извикващата задача трябва да чака. Обратно ако при изпълнението на accept няма постъпила заявка за съответният вход,обслужващата чака до постъпването на такава. Рандевунастъпва в момента, когато извикването се приеме. Извикващата задача чака, докато обслужващата задача изпълни действията, включени в accept. Ако има резултати, те се връщат в чрез параметрите и двете зададчи продължават независимата си работа. По този начин се оцъществява синхронизацията и комуникацията между два процеса.Всяко описание на задача включва спецификация(задава името на задача и имена на входовете) и тяло(описва действията изпълнявани при всяко извикване).Съществуват и по-сложни варианти на accept- условен(защитен) форма:when булев израз accept и селктивен оператор-форма: select [ when булев израз] accept [ оператори ] {or [ when булев израз ] accept } [ оператори ] [ else оператори ] end select; . Всички булеви изрази се изчисляват и ако има стойност true, съответният accept се бележи като открит. Когато могат да се избират няколко оператори се определя един случайно.Ако не може да бъде избран никой се изпълнява частта след else .Ако няма открити оператори и няма else настъпва изключителна ситуация. Като алтернатива в select вместо accept може да се използва delay (задържане) или terminate (завършване). Първата алтернатива се прилага, когато след указано в секунди закъснение не е избрана никаква друга. Втората алтернатива се избира, когато всички извикващи задачи завършват- тогава и обслужващата задача завършва. Ада има и много други допълнителни възможности- например задачите могат да имат приоритет, задача може принудително да прекрати друга задача(abort).

3.5.CSP пероцеси. Програмата на CSP съдържа фиксиран брой процеси и комуникация настъпва, когато при изход един процес именува друг като получател, а втория процес именува първият като източник за вход. Прехвърлянето на съобщение настъпва само, когато и двата процеса изпълняват съответните команди за вход и изход. Съобщенията имат типове. Този механисъм реализира синхронизацията и комуникацията между процесите.Команда за изход: потребител !х (изпрати х към потребителя). Команда за вход: производител ?у (получи от производител). Последователното управление се извършва от защитени конструкции, включващи защита (декларации, булеви изрази, команди за вход-всичките на задължителни) и последователност от команди след знака . Ако някой от булевите изрази има стойност folse (защитата пропада) или именуваният процес в командата за вход е завършил, тогава процесът, в кйойто е дефинтрана защитената команда, се изхвърля. В противен случай се изпълнява списъкът от команди (след изпълнението на командата за вход- ако има такава).

3.6.Процеси и канали в ОКАМ. ОКАМ (OCCAM) е прост език, разработен от фирмата Inmos, базиращ се на концепция за паралелност и комуникация и твърде близък до принципите в CSP. Основните еденици в програмите на ОКАМ са три примитивни процеса: присвояване, вход и изход. Присвояващия процес има вида: v:=e; като v получава стоиността на e . Процесите за вход и изход работят с така наречените канали, чрез които комуникират процесите. Те имат съответно вида: име на канала !променлива {процес за вход} , име на канала?израз {процес за вход} . Тяхното действие се състои в запис на стойност от канала в променливата (при вход) или изпращане на стойността на израза в канала (при изход). Каналите се декларират локално чрез служебна дума CHAN във всеки процес и съществуват, докато той се изпълнява.Каналите позволяват еднопосочна комуникация. За двупосочна комуникация са необходими два канала. Всеки канал е свързан само с два процеса поради, което не възникват конфликти при използването им. Конструкторът seg предизвиква последователно изпълнение на неговите компоненти, а par паралелно. Те терминират, когато или посладният компонент се изпълни (seg),иливсички (par). Има също конструктори if, while, alt(алтернативен подобно на CSP и ada). Възможно е да се приписват приоритети на процесите (вместо par се използва pri_par), като приоритетът се определя от мястото в списъка (в началото е този с най-голям приоритет).

3.7.Съпрограми. Съпрограмите не са подчинени модули и позволяват симетрично предаване на управлението. Превключването на процесора от една съпрограма към друга става явно с оператор resume х. Възобновяването на изпълнението на съпрограмата става от точка, където тя е била преустановена споследния resume (трябва да се запази достатъчно информация за връщане), пак с помоща на resume Така съпрограмите се изпълняват квазипаралелно (сихронизацията им става явно с resume, за разлика от средствата, използвани за сихронизация на процеси). Съпрограмите осигуряват ефективно моделиране на процеси и именно затова се използват в програмните езици.