                                -
    |          -                              P(семафор)
    |          -                         ‡начение семафора = -1
    |          -
    |         (нет)
    |       Ќ…‚…ђЌЋ !!
    v
  ‚ремЯ

    ђисунок 12.10.  Ќеудачное имитациЯ функции wakeup при исполь-
                    зовании операции V


ЋперациЯ повторЯетсЯ в цикле до тех пор, пока значение семафора не  превысит
0;  программа  обработки прерываний не приостанавливаетсЯ и цикл завершаетсЯ
только тогда, когда значение семафора станет положительным, после  чего  это
значение будет уменьшено операцией CP.
    —тобы  предотвратить  ситуацию взаимной блокировки, Ядру нужно запретить
все прерываниЯ, выполнЯющие "циклическую блокировку". €наче выполнение  про-
цесса, захватившего семафор, будет прервано еще до того, как он сможет осво-
бодить  семафор;  если  программа  обработки прерываний попытаетсЯ захватить
этот семафор, используЯ "циклическую блокировку", Ядро заблокирует само  се-
бЯ.  ‚  качестве  примера  обратимсЯ к ђисунку 12.13. ‚ момент возникновениЯ

     Џроцесс A/Џроцессор A              Џроцесс B/Џроцессор B
    +-----------------------------------------------------------
    |    P(семафор SA);                           -
    |          -                                  -
    |          -                                  -
    |          -                                  -
    |          -                            P(семафор SB);
    |          -                                  -
    |          -                                  -
    |          -                                  -
    |          -                            P(семафор SA);
    |          -                          приостанавливаетсЯ
    |          -
    |    P(семафор SB);
    |  приостанавливаетсЯ
    |
    v                  ‚заимнаЯ блокировка !!
  ‚ремЯ
                      ђисунок 12.11.   ‚озникновение тупиковой ситуации
                                   из-за смены очередности блокированиЯ

                                    373


прерываниЯ значение семафора не превышает 0, поэтому результатом выполнениЯ
операции CP всегда будет "ложь". Џроблема решаетсЯ путем запрещениЯ всех
прерываний на то времЯ, пока семафор захвачен процессом.


        12.3.3 Џримеры алгоритмов

    ‚  данном  разделе  мы рассмотрим четыре алгоритма Ядра, реализованных с
использованием семафоров. Ђлгоритм  выделениЯ  буфера  иллюстрирует  сложную
схему  блокированиЯ, на примере алгоритма wait показана синхронизациЯ выпол-
нениЯ процессов, схема блокированиЯ драйверов реализует изЯщный подход к ре-
шению данной проблемы, и наконец, метод  решениЯ  проблемы  холостой  работы
процессора  показывает,  что нужно сделать, чтобы избежать конкуренции между
процессами.


        12.3.3.1 ‚ыделение буфера

    ЋбратимсЯ еще раз к алгоритму getblk, рассмотренному нами в главе 3. Ђл-
горитм работает с тремЯ структурами данных: заголовком буфера,  хеш-очередью
буферов и списком свободных буферов. џдро свЯзывает семафор со всеми экземп-
лЯрами каждой структуры. „ругими словами, если у Ядра имеютсЯ в распорЯжении
200  буферов, заголовок каждого из них включает в себЯ семафор, используемый
длЯ захвата буфера; когда процесс выполнЯет над семафором операцию P, другие
процессы, тоже пожелавшие захватить буфер, приостанавливаютсЯ  до  тех  пор,
пока  первый  процесс  не  исполнит операцию V. “ каждой хеш-очереди буферов
также имеетсЯ семафор, блокирующий доступ к очереди. ‚ однопроцессорной сис-
теме блокировка хеш-оче-

     Џроцесс A/Џроцессор A              Џроцесс B/Џроцессор B
    +-----------------------------------------------------------
    |    P(семафор SA);                           -
    |          -                                  -
    |          -                            P(семафор SB);
    |          -                                  -
    |          -                                  -
    |          -                        если (! CP(семафор SA))
    |          -                        {
    |          -                            V(семафор SB);
    |          -                            перезапустить алго-
    |          -                             ритм
    |          -                        }
    |    P(семафор SB);
    |  приостанавливаетсЯ
    v
  ‚ремЯ

    ђисунок 12.12.   €спользование  операции P условного типа длЯ
                     предотвращениЯ взаимной блокировки


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


                                    374

туп к очереди только длЯ одного процесса. Џо тем же причинам и  список  сво-
бодных буферов нуждаетсЯ в семафоре длЯ защиты содержащейсЯ в нем информации
от искажениЯ.
    Ќа ђисунке 12.14 показана перваЯ часть алгоритма getblk, реализованнаЯ в
многопроцессорной  системе с использованием семафоров. ЏросматриваЯ буферный
кеш в поисках указанного блока, Ядро с помощью операции P захватывает  сема-
фор,  принадлежащий  хеш-очереди.  …сли над семафором уже кем-то произведена
операциЯ данного типа, текущий процесс приостанавливаетсЯ до тех  пор,  пока
процесс,  захвативший  семафор, не освободит его, выполнив операцию V. Љогда
текущий процесс получает право исключительного контролЯ над хеш-очередью, он
приступает к поиску подходЯщего буфера. Џредположим, что буфер  находитсЯ  в
хеш-очереди.  џдро (процесс A) пытаетсЯ захватить буфер, но если оно исполь-
зует операцию P и если буфер уже захвачен, Ядру придетсЯ приостановить  свою
работу,  оставив хеш-очередь заблокированной и не допускаЯ таким образом об-
ращений к ней со стороны других процессов, даже если последние  ведут  поиск
незахваченных  буферов.  Џусть вместо этого процесс A захватывает буфер, ис-
пользуЯ операцию CP; если операциЯ завершаетсЯ успешно, буфер становитсЯ от-
крытым длЯ процесса. Џроцесс A  захватывает  семафор,  принадлежащий  списку
свободных  буферов, выполнЯЯ операцию CP, поскольку семафор захватываетсЯ на
непродолжительное времЯ и, следовательно, приостанавливать свою работу,  вы-
полнЯЯ  операцию  P, процесс просто не имеет возможности. џдро убирает буфер
из списка свободных буферов, снимает блокировку со списка и с хеш-очереди  и
возвращает захваченный буфер.

    |
    |                      P(семафор);
    |            (‡начение семафора теперь равно 0)
    |
    |                       Џрерывание
    |
    |           CP(семафор) завершаетсЯ неудачно ---
    |                    семафор захвачен
    |
    |     ‘емафор не освобождаетсЯ до выхода из прерываниЯ.
    |
    |     ‚ыход из прерываниЯ без его обработки невозможен.
    |
    |          ’упиковаЯ ситуациЯ (взаимнаЯ блокировка)
    v
  ‚ремЯ

    ђисунок 12.13.   ‚заимнаЯ блокировка при выполнении программы
                     обработки прерываниЯ


    Џредположим,  что операциЯ CP над буфером завершилась неудачно из-за то-
го, что семафор, принадлежащий буферу, оказалсЯ захваченным. Џроцесс A осво-
бождает семафор, свЯзанный с хеш-очередью, и приостанавливаетсЯ, пытаЯсь вы-
полнить операцию P над семафором буфера. ЋперациЯ P над семафором будет  вы-
полнЯтьсЯ,  несмотрЯ на то, что операциЯ CP уже потерпела неудачу. Џо завер-
шении выполнениЯ операции процесс A получает власть над буфером. ’ак  как  в
оставшейсЯ  части алгоритма предполагаетсЯ, что буфер и хеш-очередь захваче-
ны, процесс A теперь пытаетсЯ захватить хеш-очередь (*).  Џоскольку  очеред-

---------------------------------------
(*) ‚место захвата хеш-очереди в этом месте можно было бы  установить  соот-
    ветствующий  флаг,  проверЯемый  далее  перед выполнением операции V, но
    чтобы проиллюстрировать схему захвата семафоров  в  обратной  последова-
    тельности,  в изложении мы будем придерживатьсЯ ранее описанного вариан-
    та.
                                    375

ность  захвата здесь (сначала семафор буфера, потом семафор очереди) обратна
вышеуказанной очередности, над семафором выполнЯетсЯ операциЯ CP.  …сли  по-
пытка захвата заканчиваетсЯ неудачей, имеет место обычнаЯ обработка, требую-
щаЯсЯ  по  ходу задачи. Ќо если захват удаетсЯ, Ядро не может быть уверено в

    +------------------------------------------------------------+
    | алгоритм getblk           /* многопроцессорнаЯ версиЯ */   |
    | входнаЯ информациЯ:  номер файловой системы                |
    |                      номер блока                           |
    | выходнаЯ информациЯ: захваченный буфер, предназначенный длЯ|
    |                      обработки содержимого блока           |
    | {                                                          |
    |    выполнЯть (пока буфер не будет обнаружен)               |
    |    {                                                       |
    |       P(семафор хеш-очереди);                              |
    |       если (блок находитсЯ в хеш-очереди)                  |
    |       {                                                    |
    |          если (операциЯ CP(семафор буфера) завершаетсЯ не- |
    |           удачно)       /* буфер занЯт */                  |
    |          {                                                 |
    |             V(семафор хеш-очереди);                        |
    |             P(семафор буфера);      /* приостанов до момен-|
    |                                      * та освобождениЯ     |
    |                                      */                    |
    |             если (операциЯ CP(семафор хеш-очереди) заверша-|
    |              етсЯ неудачно)                                |
    |             {                                              |
    |                V(семафор буфера);                          |
    |                продолжить;     /* выход в цикл "выполнЯть" |
    |                                 */                         |
    |             }                                              |
    |             в противном случае если (номер устройства или  |
    |              номер блока изменились)                       |
    |             {                                              |
    |                V(семафор буфера);                          |
    |                V(семафор хеш-очереди);                     |
    |             }                                              |
    |          }                                                 |
    |          выполнЯть (пока операциЯ CP(семафор списка свобод-|
    |           ных буферов) не завершитсЯ успешно)              |
    |             ;    /* "кольцевой цикл" */                    |
    |          пометить буфер занЯтым;                           |
    |          убрать буфер из списка свободных буферов;         |
    |          V(семафор списка свободных буферов);              |
    |          V(семафор хеш-очереди);                           |
    |          вернуть буфер;                                    |
    |       }                                                    |
    |       в противном случае   /* буфер отсутствует в хеш-     |
    |                             * очереди                      |
    |                             */                             |
    |       /* здесь начинаетсЯ выполнение оставшейсЯ части алго-|
    |        * ритма                                             |
    |        */                                                  |
    |    }                                                       |
    | }                                                          |
    +------------------------------------------------------------+

      ђисунок 12.14. ‚ыделение буфера с использованием семафоров


                                    376

том, что захвачен корректный буфер, поскольку содержимое буфера  могло  быть
ранее изменено другим процессом, обнаружившим буфер в списке свободных буфе-
ров и захватившим на времЯ его семафор. Џроцесс A, ожидаЯ освобождениЯ сема-
фора,  не  имеет  ни малейшего представлениЯ о том, ЯвлЯетсЯ ли интересующий
его буфер тем буфером, который ему нужен, и поэтому прежде всего  он  должен
убедитьсЯ  в правильности содержимого буфера; если проверка дает отрицатель-
ный результат, алгоритм запускаетсЯ сначала. …сли содержимое буфера коррект-
но, процесс A завершает выполнение алгоритма.

    +------------------------------------------------------------+
    | многопроцессорнаЯ версиЯ алгоритма wait                    |
    | {                                                          |
    |     длЯ (;;)       /* цикл */                              |
    |     {                                                      |
    |         перебор всех процессов-потомков:                   |
    |         если (потомок находитсЯ в состоЯнии "прекращениЯ   |
    |          существованиЯ")                                   |
    |              вернуть управление;                           |
    |         P(zombie_semaphore);   /* начальное значение - 0 */|
    |     }                                                      |
    | }                                                          |
    +------------------------------------------------------------+

       ђисунок 12.15. ЊногопроцессорнаЯ версиЯ алгоритма wait


    ЋставшуюсЯ часть алгоритма можно рассмотреть в качестве упражнениЯ.


        12.3.3.2 Wait

    €з главы 7 мы уже знаем о том, что во времЯ выполнениЯ системной функции
wait процесс приостанавливает свою работу до момента  завершениЯ  выполнениЯ
своего потомка. ‚ многопроцессорной системе перед процессом встает задача не
упустить  при выполнении алгоритма wait потомка, прекратившего существование
с помощью функции exit; если, например, в то времЯ, пока на одном процессоре
процесс-родитель запускает функцию wait, на другом  процессоре  его  потомок
завершил  свою  работу, родителю нет необходимости приостанавливать свое вы-
полнение в ожидании завершениЯ второго потомка. ‚ каждой записи таблицы про-
цессов имеетсЯ семафор, именуемый zombie_semaphore и имеющий в начале  нуле-
вое  значение.  ќтот  семафор  используетсЯ  при  организации взаимодействиЯ
wait/exit (ђисунок 12.15). Љогда потомок завершает работу, он выполнЯет  над
семафором  своего родителЯ операцию V, выводЯ родителЯ из состоЯниЯ приоста-
нова, если тот перешел в него во времЯ исполнениЯ функции wait. …сли потомок
завершилсЯ раньше, чем родитель запустил функцию wait, этот факт будет обна-
ружен родителем, который тут же выйдет из состоЯниЯ ожиданиЯ. …сли оба  про-
цесса  исполнЯют функции exit и wait параллельно, но потомок исполнЯет функ-
цию exit уже после того, как родитель проверил его статус, операциЯ  V,  вы-
полненнаЯ потомком, воспрепЯтствует переходу родителЯ в состоЯние приостано-
ва. ‚ худшем случае процесс-родитель просто повторЯет цикл лишний раз.


        12.3.3.3 „райверы

    ‚  многопроцессорной реализации вычислительной системы на базе компьюте-
ров AT&T 3B20 семафоры в структуру загрузочного кода драйверов не  включают-
сЯ,  а  операции типа P и V выполнЯютсЯ в точках входа в каждый драйвер (см.
[Bach 84]). ‚ главе 10 мы говорили о том, что интерфейс, реализуемый драйве-
рами устройств, характеризуетсЯ очень небольшим числом точек входа (на прак-

                                    377

тике их около 20). ‡ащита драйверов осуществлЯетсЯ на уровне точек  входа  в
них:

    P(семафор драйвера);
    открыть (драйвер);
    V(семафор драйвера);

    …сли  длЯ всех точек входа в драйвер использовать один и тот же семафор,
но при этом длЯ разных драйверов  -  разные  семафоры,  критический  участок
программы  драйвера  будет  исполнЯтьсЯ процессом монопольно. ‘емафоры могут
назначатьсЯ как отдельному устройству, так и классам устройств. ’ак,  напри-
мер, отдельный семафор может быть свЯзан и с отдельным физическим терминалом
и  со  всеми терминалами сразу. ‚ первом случае быстродействие системы выше,
ибо процессы, обращающиесЯ к терминалу, не захватывают семафор, имеющий  от-
ношение  к  другим терминалам, как во втором случае. „райверы некоторых уст-
ройств, однако, поддерживают внутреннюю свЯзь с другими драйверами; в  таких
случаЯх использование одного семафора длЯ класса устройств облегчает понима-
ние  задачи.  ‚ качестве альтернативы в вычислительной системе 3B20A предос-
тавлена возможность такого конфигурированиЯ отдельных устройств, при котором
программы драйвера запускаютсЯ на точно указанных процессорах.
    Џроблемы возникают тогда, когда драйвер прерывает работу системы  и  его
семафор  захвачен: программа обработки прерываний не может быть вызвана, так
как иначе возникла бы угроза разрушениЯ данных. ‘ другой  стороны,  Ядро  не
может оставить прерывание необработанным. ‘истема 3B20A выстраивает прерыва-
ниЯ  в  очередь  и ждет момента освобождениЯ семафора, когда вызов программы
обработки прерываний не будет иметь опасные последствиЯ.


        12.3.3.4 ”иктивные процессы

    Љогда Ядро выполнЯет переключение контекста в однопроцессорной  системе,
оно  функционирует  в  контексте процесса, уступающего управление (см. главу
6). …сли в системе нет процессов, готовых к запуску, Ядро переходит в состо-
Яние простоЯ в контексте процесса, выполнЯвшегосЯ последним. Џолучив  преры-
вание  от  таймера или других периферийных устройств, оно обрабатывает его в
контексте того же процесса.
    ‚ многопроцессорной системе Ядро не может простаивать в  контексте  про-
цесса,  выполнЯвшегосЯ  последним. Џосмотрим, что произойдет после того, как
процесс, приостановивший свою работу на процессоре A,  выйдет  из  состоЯниЯ
приостанова.  Џроцесс в целом готов к запуску, но он запускаетсЯ не сразу же
по выходе из состоЯниЯ приостанова, даже несмотрЯ на то,  что  его  контекст
уже  находитсЯ в распорЯжении процессора A. …сли этот процесс выбираетсЯ длЯ
запуска процессором B, последний переключаетсЯ на его контекст и возобновлЯ-
ет его выполнение. Љогда в результате прерываниЯ процессор A выйдет из прос-
тоЯ, он будет продолжать свою работу в контексте процесса A до тех пор, пока
не произведет переключение контекста. ’аким  образом,  в  течение  короткого
промежутка  времени с одним и тем же адресным пространством (в частности, со
стеком Ядра) будут вести работу (и, что весьма вероЯтно, производить запись)
сразу два процессора.
    ђешение этой проблемы состоит в создании некоторого фиктивного процесса;
когда процессор находитсЯ в состоЯнии простоЯ, Ядро  переключаетсЯ  на  кон-
текст  фиктивного  процесса, делаЯ этот контекст текущим длЯ бездействующего
процессора. Љонтекст фиктивного процесса состоит только из стека Ядра;  этот
процесс не ЯвлЯетсЯ выполнимым и не выбираетсЯ длЯ запуска. Џоскольку каждый
процессор  простаивает  в контексте своего собственного фиктивного процесса,
навредить друг другу процессоры уже не могут.


                                    378

        12.4 ‘€‘’…ЊЂ TUNIS

    Џользовательский интерфейс системы Tunis совместим с аналогичным  интер-
фейсом системы UNIX, но Ядро этой системы, разработанное на Языке Concurrent
Euclid,  состоит  из  процессов, управлЯющих каждой частью системы. Џроблема
взаимного исключениЯ решаетсЯ в системе Tunis довольно  просто,  так  как  в
каждый  момент  времени  исполнЯетсЯ не более одной копии управлЯемого Ядром
процесса, кроме того, процессы работают только с  теми  структурами  данных,
которые им принадлежат. ‘истемные процессы активизируютсЯ запросами на ввод,
защиту  очереди  запросов  осуществлЯет процедура программного монитора. ќта
процедура усиливает взаимное исключение, разрешаЯ доступ к своей исполнЯемой
части в каждый момент времени не более, чем одному процессу. Њеханизм  мони-
тора  отличаетсЯ  от механизма семафоров тем, что, во-первых, благодарЯ пос-
ледним усиливаетсЯ модульность программ (операции P и V присутствуют на вхо-
де в процедуру монитора и на выходе из нее),  а  во-вторых,  сгенерированный
компилЯтором  код  уже  содержит  элементы синхронизации. •олт отмечает, что
разработка таких систем облегчаетсЯ, если используетсЯ Язык,  поддерживающий
мониторы  и  включающий  понЯтие  параллелизма (см. [Holt 83], стр.190). Џри
всем при этом внутреннЯЯ структура системы Tunis отличаетсЯ от  традиционной
реализации системы UNIX радикальным образом.


        12.5 “‡Љ€… Њ…‘’Ђ ‚ ”“ЌЉ–€ЋЌ€ђЋ‚ЂЌ€€ ЊЌЋѓЋЏђЋ–…‘‘ЋђЌ›• ‘€‘’…Њ

    ‚  данной главе нами были рассмотрены два метода реализации многопроцес-
сорных версий системы UNIX: конфигурациЯ, состоЯщаЯ из главного и  подчинен-
ного  процессоров, в которой только один процессор (главный) функционирует в
режиме Ядра, и метод, основанный на использовании  семафоров  и  допускающий
одновременное  исполнение  в режиме Ядра всех имеющихсЯ в системе процессов.
Ћба метода инвариантны к количеству процессоров, однако говорить о том,  что
с  ростом числа процессоров общаЯ производительность системы увеличиваетсЯ с
линейной скоростью, нельзЯ. Џотери производительности возникают,  во-первых,
как следствие конкуренции за ресурсы памЯти, котораЯ выражаетсЯ в увеличении
продолжительности  обращениЯ к памЯти. ‚о-вторых, в схеме, основанной на ис-
пользовании семафоров, к этой конкуренции добавлЯетсЯ соперничество за сема-
форы; процессы зачастую обнаруживают семафоры захваченными, больше процессов
находитсЯ в очереди, долгое времЯ ожидаЯ получениЯ доступа к семафорам. Џер-
ваЯ схема, основаннаЯ на использовании главного и подчиненного  процессоров,
тоже  не  лишена  недостатков:  по мере увеличениЯ числа процессоров главный
процессор становитсЯ узким местом в системе, поскольку только он один  может
функционировать в режиме Ядра. ЌесмотрЯ на то, что более внимательное техни-
ческое  проектирование позволЯет сократить конкуренцию до разумного минимума
и в некоторых случаЯх приблизить скорость повышениЯ производительности  сис-
темы при увеличении числа процессоров к линейной (см., например, [Beck 85]),
все  построенные  с  использованием современной технологии многопроцессорные
системы имеют предел, за которым расширение состава процессоров не сопровож-
даетсЯ увеличением производительности системы.


        12.6 “ЏђЂ†Ќ…Ќ€џ

  1. ђешите проблему функционированиЯ многопроцессорных систем  таким  обра-
     зом,  чтобы все процессоры в системе могли функционировать в режиме Яд-
     ра, но не более одного одновременно. ’акое решение будет отличатьсЯ  от
     первой  из предложенных в тексте схем, где только один процессор (глав-
     ный) предназначен длЯ реализации функций Ядра. Љак добитьсЯ того, чтобы
     в режиме Ядра в каждый момент времени находилсЯ только один процессор ?
     Љакую стратегию обработки прерываний при этом можно считать приемлемой?


                                    379

  2.  €спользуЯ системные функции работы с разделЯемой областью памЯти, про-
     тестируйте программу, реализующую семафорную блокировку (ђисунок 12.6).
     Џоследовательности операций P-V над семафором могут независимо один  от
     другого выполнЯть несколько процессов. Љаким образом в программе следу-
     ет реализовать индикацию и обработку ошибок ?
  3. ђазработайте алгоритм выполнениЯ операции CP (условный тип операции P),
     используЯ текст алгоритма операции P.
  4. ЋбъЯсните, зачем в алгоритмах операций P и V (ђисунки 12.8 и 12.9) нуж-
     на блокировка прерываний. ‚ какие моменты ее следует осуществлЯть ?
  5. Џочему при выполнении "циклической блокировки" вместо строки:
                while (! CP(семафор));
     Ядро  не  может использовать операцию P безусловного типа ? (‚ качестве
     наводЯщего вопроса: что произойдет в том случае, если процесс  запустит
     операцию P и приостановитсЯ ?)
  6.  ЋбратимсЯ к алгоритму getblk, приведенному в главе 3. Ћпишите реализа-
     цию алгоритма в многопроцессорной системе длЯ случаЯ, когда блок отсут-
     ствует в буферном кеше.
 *7. Џредположим, что при выполнении  алгоритма  выделениЯ  буфера  возникла
     чрезвычайно  сильнаЯ  конкуренциЯ за семафор, принадлежащий списку сво-
     бодных буферов. ђазработайте схему ослаблениЯ конкуренции за счет  раз-
     биениЯ списка свободных буферов на два подсписка.
 *8. Џредположим, что у терминального драйвера имеетсЯ семафор, значение ко-
     торого при инициализации сбрасываетсЯ в 0 и по которому процессы приос-
     танавливают  свою  работу в случае переполнениЯ буфера вывода на терми-
     нал. Љогда терминал готов к приему следующей порции данных, он  выводит
     из  состоЯниЯ ожиданиЯ все процессы, приостановленные по семафору. ђаз-
     работайте схему возобновлениЯ процессов, использующую операции типа P и
     V. ‚ случае необходимости введите дополнительные флаги и семафоры.  Љак
     должна вести себЯ схема в том случае, если процессы выводЯтсЯ из состо-
     ЯниЯ  ожиданиЯ  по  прерыванию,  но при этом текущий процессор не имеет
     возможности блокировать прерываниЯ на других процессорах ?
 *9. …сли точки входа в драйвер защищаютсЯ  семафорами,  должно  соблюдатьсЯ
     условие  освобождениЯ  семафора  в случае перехода процесса в состоЯние
     приостанова. Љак это реализуетсЯ на практике  ?  Љаким  образом  должна
     производитьсЯ  обработка прерываний, поступающих в то времЯ, пока сема-
     фор драйвера заблокирован ?
 10. ЋбратимсЯ к системным функциЯм установки и контролЯ системного  времени
     (глава  8).  ђазные  процессоры могут иметь различную тактовую частоту.
     Љак в этом случае указанные функции должны работать ?


                                    380