Добавил:
Я и кто? Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Билеты РОС.docx
Скачиваний:
23
Добавлен:
10.09.2023
Размер:
1.18 Mб
Скачать

1. Понятие job, task и process ос. Каковы способы взаимодействия процессов распределенной ос.

Лекция

Операционная система создает кучу расписаний (schedule).

1. Когда у меня создается какой-то процесс, он создается на диске. И на диске валяется исходный код.

2. Потом мы его компилируем

3. Потом при помощи binder собираем, и это все еще валяется на диске.

4. И вот то, что теперь валяется на диске называется Job.

5. Как только я загрузил при помощи louder этот Job в RAM, я получил task/program/process.

6. В RAM оно загружается в стек и находится внизу этого стека. И вот то, что загрузилось вниз стека, называется text.

(лучше почитайте фул 3 лекцию, тут только вырезку вставлю)

Есть процессы, которые между собой взаимосвязаны, а есть независимые и ОС должна этим заняться, это её функции. Также ОС должна выяснять, какой процесс после какого процесса можно запускать, а какой нельзя.

Таким образом, должна быть Process communication и Process synchronization (Коммуникация процессов и синхронизация процессов), расписание процессов (scheduler), как для них делится CPU (ЦПУ). Есть бит, который говорит в каком режиме мы работаем, в юзеровском или system mode. Коммуникация происходит через разделяемую память, сообщениями и сокетами. Это всё работает при централизованной обработке.

При нецентрализованной обработке есть другие способы коммуникации процессов. Например: shared memory (разделяемая память). Я разделю память и при помощи ОС я скажу, что эти ресурсы я выделила как буфера для того, чтобы обмениваться параметрами между процессами и какой-то процесс получит что-то от другого. Такая история бывает mandatory (обязательный в переводе), то есть я делаю это через ОС, а бывает, что процессы делятся при помощи POSIX, API всяких и в этом случае, здесь всё процессы делятся сами. Здесь память не защищается операционной системой. Protection нет в этом случае. Это из-за того, что вторая система multi process, но не multi users. У windows это mandatory, у UNIX это каждый сам себя защищает. Классно получается, то есть плохо!

Такая shared memory нам не годится, поэтому IBM придумали MPS (message passing system). Это то, что мы называем сокетами. Они сказали: мы будем общаться между процессами с помощью ящиков (mail box). Mail box – область памяти. Память – array of words (массив слов). Какие-то слова я выделила под то, чтобы указать адрес того, где будет запускаться процесс, pointer. Pointer указывает на адрес процесса. Мы передаём мейл бокс, адрес его, а по этому адресу будет лежать pointer, который запускает соответствующий процесс.

Если мы коммуницируем в варианте shared memory, то для связи процессов между собой и их переключения есть аппарат inter-process communication intercell. Это специальные системные вызовы, system call, которые есть в любой ОС, но если у нас вот эта канитель распределённая, то нас это не устроит. И тут появляется самый частый вариант в виде computation migration. Это основная технология для связи и запуска процессов между собой. В такой технологии не сокеты, не месседжы (messages), а технология RPC.

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

Коммуникация процессов в большинстве своём происходит через RPC библиотеки. Они идут в составе любого программного продукта. Например XML RPC. Это текстовый протокол для HTTP. Для джавы - java RMI. Remote method invocation. Это специальное RPC, но для джавы. Этих RPC масса.

Каждое сообщение, которое адресуется для процесса, который использует RPC, оно слушает порт на удалённой системе. Каждое сообщение имеет функцию и параметры. По 1 адресу может быть много портов. На каждой станции и на каждом сервере заводится stub (стаб). Он определяет по какому порту мы будем запускать процесс и с какими параметрами. Причём как на станции, так и на сервере. Похожий stub(стаб) на сервере будет принимать соответствующую процедуру и, если надо, возвращать код какой-то. Stub входит в состав таких библиотек.

(в книге инфы не нашла)