Документы



Лекция 1 Функционирование в «Реальном мас­штабе времени» icon

Лекция 1 Функционирование в «Реальном мас­штабе времени»

НазваниеЛекция 1 Функционирование в «Реальном мас­штабе времени»
страница1/11
Дата07.06.2013
Размер2.63 Mb.
ТипЛекция
скачать
  1   2   3   4   5   6   7   8   9   10   11


Лекция 1 Функционирование в «Реальном мас­штабе времени»


В настоящее время в документах и публикациях с различной те­матикой встречаются слова о требовании, поддержке и т.д. «работы в режиме реального времени», «режима реального времени» или про­сто «реального времени». Что же такое «режим реального времени» применительно к компьютерным системам? Постараемся представить различные современные точки зрения на это понятие.

Толковый словарь по вычислительным системам [7], дает такое определение

R.052 real-time system система реального времени (СРВ)

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

В толковом словаре по информатике [8] дается такое определе­ние (стр. 335): Режим реального времени [real time processing]. Режим

обработки данных, при котором обеспечивается взаимодействие вы­числительной системы с внешними по отношению к ней процессами в темпе, соизмеримом со скоростью протекания этих процессов.

Каноническое определение системы реального времени дано Дональдом Гиллиесом и выглядит так:

«Системой реального времени является такая система, коррект­ность функционирования которой определяется не только корректно­стью выполнения вычислений, но и временем, в которое получен тре­буемый результат. Если требования по времени не выполняются, то считается, что произошел отказ системы». Другие добавляют: «По­этому необходимо, чтобы было гарантировано [аппаратными и про­граммными средствами и алгоритмами обработки] выполнение тре­бований по времени. Гарантия выполнения требований по времени необходима, чтобы поведение системы было предсказуемо. Также желательно, чтобы система обеспечивала высокую степень использо­вания ресурсов, чтобы удовлетворять требованиям по времени [с ми­нимальными затратами]».

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

Другой пример - цикл управления самолетом, летящим на авто­пилоте. Датчики самолета должны постоянно передавать измеренные данные в управляющий компьютер. Если данные измерений теряют­ся, то качество управления самолетом падает, возможно вместе с са­молетом.

Отметим следующую особенность: в примере с роботом и имеем настоящий, «жесткий» режим реального времени (hard real time), и если робот опоздает, то это приведет к полностью ошибочной опера­ции. Однако это мог бы быть режим «квазиреального» времени (soft real time), если бы опоздание робота приводило бы только к потере производительности. Многое из того, что сделано в области про­граммирования в реальном времени, в действительности работает в режиме «квазиреального» времени. Грамотно разработанные систе­мы, как правило, имеют уровень безопасности/коррекции поведения

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

Бывает, что термин «система реального времени» применяют в значении «интерактивная система» (on-line). Часто это просто рек­ламный ход. Например, системы заказа билетов или системы склад­ского учета не являются системами «реального времени», так как че­ловек-оператор без проблем перенесет задержку ответа на несколько сотен миллисекунд.

Также можно встретить случаи, когда термин «система реально­го времени» применяют просто в значении «быстродействующая сис­тема». Необходимо отметить, что определение «реального времени» не является синонимом для определения «быстродействующая». Еще раз: термин «система реального времени» не означает, что система дает ответ на воздействие мгновенно - задержка может достигать се­кунд и более - но означает тот факт, что гарантируется некоторая максимально возможная величина задержки ответа, что позволяет системе решать поставленную задачу. Необходимо также отметить, что алгоритмы, обеспечивающие гарантированное время ответа, час­то имеют меньшую среднюю производительность, чем алгоритмы, которые не гарантируют время ответа.

Из приведенного выше можно сделать выводы:

- термин «система реального времени» в настоящее время мо­жет быть записан так: "Системой реального времени является такая система, корректность функционирования которой определяется не только корректностью выполнения вычислений, но и временем, в ко­торое получен требуемый результат. Если требования по времени не выполняются, то считается, что произошел отказ системы".

Для того чтобы система могла удовлетворить требованиям, предъявляемым к системам реального времени, аппаратные, про­граммные средства и алгоритмы работы системы должны гарантиро­вать заданные временные параметры реакции системы. Время реак­ции не обязательно должно быть очень маленьким, но оно должно быть гарантированным (и отвечающим поставленным требованиям);

- использование термина «система реального времени», опреде­ленного выше, для обозначения интерактивных и высокопроизводи­тельных систем неверно;

- термин «квазиреальное время» (soft real-time) хотя и использу­ется, но четко не определен. До его четкого определения вряд ли воз­можно его применение в документах (кроме рекламных). С уверен­ностью можно сказать, что смысл термина «реальное время» тракту­ется специалистами по-разному в зависимости от области их профес­сиональных интересов, от того, являются они теоретиками или прак­тиками, и даже просто отличного опыта и круга общения.

- практически все системы промышленной автоматизации явля­ются системами реального времени.

- принадлежность системы к классу систем реального времени никак не связана с ее быстродействием. Например, если ваша система предназначена для контроля уровня грунтовых вод, то даже выполняя измерения с периодичностью один раз за полчаса, она будет работать в реальном времени.

Исходные требования к времени реакции системы и другим временным параметрам определяются или техническим заданием на систему, или просто логикой ее функционирования. Например, шах­матная программа, думающая над каждым ходом более года, работает явно не в реальном времени, так как шахматист скорее всего не до­живет до конца партии. Однако точное определение «приемлемого времени реакции» не всегда является простой задачей, а в системах, где одним из звеньев служит человек, подвержено влиянию субъек­тивных факторов. Впрочем, человек - это своеобразная вычислитель­ная машина.

Интуитивно понятно, что быстродействие системы реального времени должно быть тем больше, чем больше скорость протекания процессов на объекте контроля и управления. Чтобы оценить необхо­димое быстродействие для систем, имеющих дело со стационарными процессами, часто используют теорему Котельникова [6], из которой следует, что частота дискретизации сигналов должна быть как мини­мум в 2 раза выше граничной частоты их спектра.

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

цесса, иначе информация будет потеряна. Подобные системы иногда называют системами квази-реального времени.

Принято различать системы «жесткого» и «мягкого» реального времени. Эти различия не связаны с органолептическими свойствами систем. Тогда что же это такое?

1. Системой «жесткого» реального времени называется система, где неспособность обеспечить реакцию на какие-либо события в за­данное время является отказом и ведет к невозможности решения по­ставленной задачи.

Последствия таких отказов могут быть разные, от пролива дра­гоценной влаги на линии по розливу алкогольных напитков до более крупных неприятностей, если, например, вовремя не сработала сис­тема аварийных блокировок атомного реактора.

Многие теоретики ставят здесь точку, из чего следует, что время реакции в «жестких» системах может составлять и секунды, и часы, и недели. Однако большинство практиков считают, что время реакции в системах «жесткого» реального времени должно быть все-таки ми­нимальным. Идя на поводу у практиков, так и будем считать. Разуме­ется, однозначного мнения о том, какое время реакции свойственно «жестким» системам, нет. Более того, с увеличением быстродействия микропроцессоров это время имеет тенденцию к уменьшению, и если раньше в качестве границы называлось значение 1 мс, то сейчас, как правило, называется время порядка 100 мкс.

2. Точного определения для «мягкого» реального времени не существует, поэтому будем считать, что сюда относятся все системы реального времени, не попадающие в категорию «жестких».

Так как система «мягкого» реального времени может не успе­вать все делать ВСЕГДА в заданное время, возникает проблема опре­деления критериев успешности (нормальности) ее функционирова­ния. Вопрос этот совсем не простой, так как в зависимости от функ­ций системы это может быть максимальная задержка в выполнении каких-либо операций, средняя своевременность отработки событий и т. п. Более того, эти критерии влияют на то, какой алгоритм планиро­вания задач является оптимальным. Вообще говоря, системы «мягко­го» реального времени проработаны теоретически далеко не до кон­ца.


^ Лекция2. Задачи, процессы, потоки


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

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

Хорошим примером многопоточной программы является редак­тор текста WORD, где в рамках одного приложения может одновре­менно происходить и набор текста, и проверки правописания.

Преимущества потоков.

1. Так как множество потоков способно размещаться внутри од­ного .ЕХE-модуля, это позволяет экономить ресурсы как внешней, так и внутренней памяти.

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

3. Как правило, контекст потоков меньше, чем контекст процес­сов, а значит, время переключения между задачами-потоками мень­ше, чем между задачами-процессами.

4. Так как все потоки, а иногда и само ядро РВ размещаются в одном ЕХЕ-модуле, значительно упрощается использование про­грамм-отладчиков (debugger).

Недостатки потоков.

1. Как правило, потоки не могут быть подгружены динамически. Чтобы добавить новый поток, необходимо провести соответствую щие изменения в исходных текстах и перекомпилировать приложе

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

2. То, что потоки имеют доступ к областям данных друг друга, может привести к ситуации, когда некорректно работающий поток способен испортить данные другого потока. В отличие от этого про­цессы защищены от взаимного влияния, а попытка записи в «не свою» память приводит, как правило, к возникновению специального прерывания по обработке «исключительных ситуаций».

Реализация механизмов управления процессами и потоками, возможность их взаимного сосуществования и взаимодействия опре­деляются конкретным ПО РВ.

^ 2.2. Основные свойства задач

Как правило, вся важная, с точки зрения операционной системы, информация о задаче хранится в унифицированной структуре данных - управляющем блоке (Task Control Block, TCB). В блоке хранятся та­кие параметры, как имя и номер задачи, верхняя и нижняя границы стека, ссылка на очередь сообщений, статус задачи, приоритет и т. п.

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

^ Контекст задачи - это набор данных, содержащий всю необхо­димую информацию для возобновления выполнения задачи с того места, где она была ранее прервана. Часто контекст хранится в TCB и включает в себя такие данные, как счетчик команд, указатель стека, регистры CPU и FPU и т. п. Планировщик задач в случае необходи­мости сохраняет контекст текущей активной задачи и восстанавлива­ет контекст задачи, назначенной к исполнению. Такое переключение

контекстов и является, по сути, основным механизмом ОС РВ при пе­реходе от выполнения одной задачи к выполнению другой.

^ Состояние (статус) задачи. С точки зрения операционной сис­темы, задача может находиться в нескольких состояниях. Число и на­звание этих состояний различаются от одной ОС к другой. По-видимому, наибольшее число состояний задачи определено в языке Ada. Тем не менее, практически в любой ОС РВ загруженная на вы­полнение задача может находиться, по крайней мере, в трех состоя­ниях.

1. Активная задача - это задача, выполняемая системой в теку­щий момент времени.

2. Готовая задача - это задача, готовая к выполнению и ожи­дающая у планировщика своей «очереди».

3. Блокированная задача - это задача, выполнение которой при­остановлено до наступления определенных событий. Такими собы­тиями могут быть освобождение необходимого задаче ресурса, по­ступление ожидаемого сообщения, завершение интервала ожидания и т. п.

^ Пустая задача (Idle Task) - это задача, запускаемая самой опе­рационной системой в момент инициализации и выполняемая только тогда, когда в системе нет других готовых для выполнения задач. Пустая задача запускается с самым низким приоритетом и, как пра­вило, представляет собой бесконечный цикл «ничего не делать». На­личие пустой задачи предоставляет операционной системе удобный механизм отработки ситуаций, когда нет ни одной готовой к выпол­нению задачи.

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

Реентерабельность (повторная входимость) означает возмож­ность без негативных последствий временно прервать выполнение

какой-либо функции или подпрограммы, а затем вызвать эту функ­цию или подпрограмму снова. Частным проявлением реентерабель­ности является рекурсия, когда тело подпрограммы содержит вызов самой себя. Классическим примером нереентерабельной системы яв­ляется DOS, a типичной причиной нереентерабельности служит ис­пользование глобальных переменных. Предположим, что у нас есть функция, реализующая низкоуровневую запись на диск, и пусть она использует глобальную переменную write_sector, которая устанавли­вается в соответствии с параметром, передаваемым этой функции при вызове. Предположим теперь, что Задача А вызывает эту функцию с параметром 3, то есть хочет записать данные в сектор номер 3. До­пустим, что когда переменная write_sector уже равна 3, но сама за­пись еще не произведена, выполнение Задачи А прерывается и начи­нает выполняться Задача В, которая взывает ту же функцию, но с ар­гументом 10. После того как запись в сектор номер 10 будет произве­дена, управление рано или поздно вернется к Задаче А, которая про­должит работу с того же места. Однако, так как переменная write_sector имеет теперь значение 10, данные Задачи А, предназна­чавшиеся для сектора номер 3, будут вместо этого записаны в сектор номер 10. Из приведенного примера видно, что ошибки, связанные с нереентерабельностью, трудно обнаружить, а последствия они могут вызвать самые катастрофические.


Лекция 3. Планирование и синхронизация задач

3.1 Планирование


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

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

1. Подпрограммы не должны содержать циклов ожидания, в стиле

2. Подпрограммы должны выполнять свою работу как можно быстрее, чтобы дать возможность работать следующей подпрограм­ме.

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

Можно отметить следующие преимущества циклического алго­ритма.

1. Простота использования и прозрачность для понимания.

2. Если исключить из рассмотрения прерывания, система полно­стью детерминирована. Задачи всегда вызываются в одной и той же последовательности, что позволяет достаточно просто произвести анализ «наихудшего случая» и вычислить максимальную задержку.

3. Минимальные размеры кода и данных. Кроме того, в отличие от алгоритмов с вытеснением, для всех задач необходим только один стек.

4. Отсутствуют ошибки, обусловленные «гонками».

К недостаткам циклического алгоритма можно отнести отсутст­вие приоритетности и очередей. К тому же задачи вызываются неза­висимо от того, должны ли они в данный момент что-либо делать или нет, а на прикладного программиста ложится максимальная ответст­венность за работоспособность системы.

Перейдем теперь к другому широко используемому алгоритму планирования. Речь пойдет о режиме разделения времени. Существу­ют различные реализации в рамках этого алгоритма, и некоторые за­падные специалисты даже различают такие, в общем-то идентичные для нас понятия, как time-slicing (нарезание времени) и time-sharing (разделение времени). Как правило, алгоритм реализуется следующим образом: каждой задаче отводится определенное количество квантов времени (обычно кратно 1 мс), в течение которых задача может мо­нопольно занимать процессорное время. После того как заданный ин­тервал времени истекает, управление передается следующей готовой к выполнению задаче, имеющей наивысший приоритет. Та, в свою очередь, выполняется в течение отведенного для нее промежутка вре­мени, после чего все повторяется в стиле round robin. Легко заметить, что такой алгоритм работы может привести к определенным пробле­мам. Представим, что в системе работают 7 задач, 3 из которых име­ют высокий приоритет, а 4 - низкий. Низкоприоритетные задачи мо­гут никогда не получить управление, так как три высокоприоритет­ные задачи будут делить все процессорное время между собой. Един­ственную возможность для низкоприоритетных задач получить управление предоставляет ситуация, когда все высокоприоритетные задачи находятся в блокированном состоянии.

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

^ Кооперативная многозадачность - это еще один алгоритм пе­реключения задач, с которым широкие массы компьютерной общест­венности знакомы по операционной системе Windows.. Задача, полу­чившая управление, выполняется до тех пор, пока она сама по своей

инициативе не передаст управление другой задаче. По сути это про­должение идеологии round robin, и нет нужды объяснять, почему ал­горитм кооперативной многозадачности в чистом виде мало приме­няется в системах реального времени.

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

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

В общем случае алгоритмы планирования должны соответство­вать критериям оптимальности функционирования системы. Однако, если для систем «жесткого» реального времени такой критерий оче­виден: «ВСЕГДА и ВСЁ делать вовремя», то для систем «мягкого» реального времени это может быть, например, минимальное «макси­мальное запаздывание» или средневзвешенная своевременность за­вершения операций. В зависимости от критериев оптимальности мо­гут применяться алгоритмы планирования задач, отличные от рас­смотренных. Например, может оказаться, что планировщик должен анализировать момент выдачи критичных по времени управляющих воздействий и запускать на выполнение ту задачу, которая отвечает за ближайшие из них (алгоритм earliest deadline first, EDF).

Необходимо отметить, что в одной вычислительной системе мо­гут одновременно сосуществовать задачи и «жесткого», и «мягкого» реального времени, и что только одна из этих задач, обладающая наивысшим приоритетом, может быть по-настоящему де­терминированной.

Не стоит особо увлекаться приоритетами. Если система нор­мально работает, когда все задачи имеют одинаковый приоритет, то и слава Богу. Если нет, то можно присвоить высокий приоритет «кри­тической» задаче, и низкий приоритет всем остальным. Если у вас больше одной «критической» задачи, при недостаточном быстродей­ствии системы имеет смысл рассмотреть многопроцессорную кон­фигурацию или, отказавшись от ПО РВ, перейти к простому цикличе­скому алгоритму.

Как правило, разработчики стараются свести свою систему ре­ального времени к наиболее простым конфигурациям, характерным для систем «жесткого» реального времени, иногда даже в ущерб эф­фективности использования вычислительных ресурсов. Причина по­нятна: сложные динамические системы весьма трудно анализировать и отлаживать, поэтому лучше заплатить за более мощный процессор, чем иметь в будущем проблемы из-за непредвиденного поведения системы. В связи с этим большинство существующих систем реаль­ного времени представляют собой статические системы с фиксиро­ванными приоритетами. Часто в системе реализуется несколько «ре­жимов» работы, каждый из которых имеет свой набор выполняемых задач с заранее заданными приоритетами. Значительная часть особо ответственных систем по-прежнему реализуется без применения коммерческих ОС РВ вообще.

  1   2   3   4   5   6   7   8   9   10   11



Похожие:

Лекция 1 Функционирование в «Реальном мас­штабе времени» iconКонкурс для поставки программного продукта Bandwidth Splitter
Ля распределения трафика по объёму и скорости, а также подробного мониторинга всех клиентов и их соединений в реальном времени. Bandwidth...
Лекция 1 Функционирование в «Реальном мас­штабе времени» iconДокументы
1. /лекция/киме лекция кк.doc
Лекция 1 Функционирование в «Реальном мас­штабе времени» iconДокументы
1. /лекция/Цито Лекция.doc
Лекция 1 Функционирование в «Реальном мас­штабе времени» iconДокументы
1. /лекция/суу ва тузлар лекция кк.doc
Лекция 1 Функционирование в «Реальном мас­штабе времени» iconДокументы
1. /лекция/Агроэкология лекция кк.doc
Лекция 1 Функционирование в «Реальном мас­штабе времени» iconДокументы
1. /лекция/Tex.doretiw.лекция.doc
Лекция 1 Функционирование в «Реальном мас­штабе времени» iconДокументы
1. /лекция/Mif-10.мат тарийхы лекция.doc
Лекция 1 Функционирование в «Реальном мас­штабе времени» iconДокументы
1. /лекция/ХОМ лекция кк.doc
Лекция 1 Функционирование в «Реальном мас­штабе времени» iconДокументы
1. /лекция/хим-тех лекция.кк.doc
Лекция 1 Функционирование в «Реальном мас­штабе времени» iconДокументы
1. /лекция/эколог.монитор.лекция кк.doc

Разместите кнопку на своём сайте:
Документы


База данных защищена авторским правом ©uz.denemetr.com 2000-2015
При копировании материала укажите ссылку.
обратиться к администрации