47)Клиент-серверная взаимосвязь как один из видов коммуникации процессов.

Клиент-серверная взаимосвязь – один из наиболее распространенных видов коммуникации процессов

Используются, в частности, следующие ее разновидности:

• Сокеты (Sockets) - предназначены для взаимодействия между клиентом и сервером в сетях TCP/IP через порт с определенным номером, при котором информация передается через последовательные потоки.

• Удаленные вызовы процедур (Remote Procedure Calls – RPC) - удаленный вызов процедуры позволяет вызвать процедуру на другом компьютере локальной сети с использованием процедур-заглушек. осуществляющих выстраивание и передачу параметров и результатов.

• Удаленные вызовы методов (Remote Method Invocation – RMI) - удаленный вызов метода – объектно-ориентированный механизм Java-технологии, аналогичный удаленному вызову процедуры.

Сокеты – наиболее распространенный способ связи клиента и сервера в сети. Впервые они были реализованы в UNIX BSD 4.2. Сокет можно определить как отправную (конечную) точку для коммуникации - endpoint for communication. Сокет создается клиентом для взаимодействия с сервером. Сокет связан с определенным номером порта, через который клиент и сервер обмениваются информацией, используя числовой или символьный последовательный поток. Сервер, со своей стороны, прослушивает порт с заданным номером и создает для этого серверный сокет. По сути дела, сокет можно представлять как конкатенацию IP-адреса и порта. Например, сокет 161.25.19.8:1625 ссылается на порт 1625 на машине (хосте) 161.25.19.8. Коммуникация осуществляется между парой сокетов – клиентским и серверным.

Удаленные вызовы процедур (Remote Procedure Calls – RPC) впервые предложены фирмой Sun и реализованы в ОС Solaris.

Удаленный вызов процедуры (RPC) – абстракция вызова процедуры между процессами в сетевых системах. Он основан на следующей идее. В клиентской части создаются заглушка (proxy, stub) – локальная процедура, осуществляющая связь с фактической процедурой, находящейся на сервере. Заглушка в клиентской части находит сервер и выстраивает (marshals) параметры для их передачи на сервер по сети. Проблема здесь в том, что адресация на клиенте и на сервере различная, и передавать адрес в памяти каких-либо данных с одного хоста на другой не имеет смысла. Поэтому приходится использовать особую форму передачи информации в виде последовательного потока байтов. Заглушка в серверной части принимает сообщение, распаковывает параметры, преобразует их к нормальному виду и выполняет процедуру на сервере.

Удаленный вызов метода (Remote Method Invocation, RMI) – механизм в Java-технологии, аналогичный RPC, но в объектно-ориентированной форме.

RMI позволяет Java-приложению на одной машине вызвать метод удаленного объекта.

Схема RMI.

48)Потоки и многопоточное выполнение программ.

Однопоточные и многопоточные процессы

Последовательный (однопоточный) процесс – это процесс, который имеет только один поток управления (control flow), характеризующийся изменением его счетчика команд. Поток (thread) – это запускаемый из некоторого процесса особого рода параллельный процесс, выполняемый в том же адресном пространстве, что и процесс-родитель. Схема организации однопоточного и многопоточного процессов изображена на рис. 1.

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

Многопоточность имеет большие преимущества:

• Увеличение скорости (по сравнению с использованием обычных процессов). Многопоточность основана на использовании облегченных процессов (lightweight processes),работающих в общем пространстве виртуальной памяти. Благодаря многопоточности, не возникает больше неэффективных ситуаций, типичных для классической системы UNIX, в которой каждая команда shell (даже команда вывода содержимого текущей директории ls исполнялась как отдельный процесс, причем в своем собственном адресном пространстве. В противоположность облегченным процессам, обычные процессы (имеющие собственное адресное пространство) часто называют тяжеловесными (heavyweight).

• Использование общих ресурсов. Потоки одного процесса используют общую память и файлы.

• Экономия. Благодаря многопоточности, достигается значительная экономия памяти, по причинам, объясненным выше. Также достигается и экономия времени, так как переключение контекста на облегченный процесс, для которого требуется только сменить стек и восстановить значения регистров, значительно быстрее, чем на обычный процесс.

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

Пользовательские потоки и потоки ядра

Модели многопоточности. Реализация многопоточности в ОС, как и многих других возможностей, имеет несколько уровней абстракции. Самый высокий из них – пользовательский уровень. С точки зрения пользователя и его программ, управление потоками реализовано через библиотеку потоков пользовательского уровня (user threads) Отметим, что существует несколько моделей потоков пользовательского уровня.

Низкоуровневые потоки, в которые отображаются пользовательские потоки, называются потоками ядра (kernel threads).Они поддержаны и используются на уровне ядра операционной системы. Как и подходы к пользовательским потокам, подходы к архитектуре и реализации системных потоков и к отображению пользовательских потоков в системные в разных ОС различны. Например, собственные модели потоков ядра со своей спецификой реализованы в следующих ОС:

• Windows 95/98/NT/2000/XP/2003/2008/7;

• Solaris;

• Tru64 UNIX;

• BeOS;

• Linux.

Существуют различные модели многопоточности – способы отображения пользовательских потоков в потоки ядра. Теоретически возможны (и на практике реализованы) следующие модели многопоточности:

- Модель много / один (many-to-one) – отображение нескольких пользовательских потоков в один и тот же поток ядра. Используется в операционных системах, не поддерживающих множественные системные потоки (например, с целью экономии памяти).

Модель один / один (one-to-one) – взаимно-однозначное отображение каждого пользовательского потока в определенный поток ядра. Примеры ОС, использующих данную модель, - Windows 95/98/NT/2000/XP/2003/2008/7; OS/2.

Потоки в Windows 2000

Как уже отмечалось, в системе Windows реализована модель многопоточности "один / один". Каждый поток содержит:

• идентификатор потока (thread id);

• набор регистров

• отдельные стеки для пользовательских и системных процедур;

• область памяти для локальных данных потока (thread-local storage – TLS).

Проблемы многопоточности

Многопоточность – весьма сложная, еще не полностью изученная и, тем более, не полностью формализованная область, в которой имеется много интересных проблем. Рассмотрим некоторые из них.

Семантика системных вызовов fork() и exec().Как уже отмечалось, в классической ОС UNIX системный вызов fork создает новый "тяжеловесный" процесс со своим адресным пространством, что значительно "дороже", чем создание потока. Однако, с целью поддержания совместимости программ снизу вверх, приходится сохранять эту семантику, а многопоточность вводить с помощью новых системных вызовов.

Прекращение потоков. Важной проблемой является проблема прекращения потоков: например, если родительский поток прекращается, то должен ли при этом прекращаться дочерний поток? Если прекращается стандартный процесс, создавший несколько потоков, то должны ли прекращаться все его потоки? Ответы на эти вопросы в разных ОС неоднозначны.

Обработка сигналов. Сигналы в UNIX – низкоуровневый механизм обработки ошибочных ситуаций. Примеры сигналов: SIGSEGV - нарушение сегментации (обращение по неверному адресу, чаще всего по нулевому); SIGKILL – сигнал процессу о выполнении команды kill его уничтожения. Пользователь может определить свою процедуру-обработчик сигнала системным вызовом signal. Проблема в следующем: как распространяются сигналы в многопоточных программах и каким потоком они должны обрабатываться? В большинстве случаев этот вопрос решается следующим образом: сигнал обрабатывается потоком, в котором он сгенерирован, и влияет на исполнение только этого потока. В более современных ОС (например, Windows 2000 и более поздних версиях Windows), основанных на объектно-ориентированной методологии, концепция сигнала заменена более высокоуровневой концепцией исключения (exception).Исключение распространяется по стеку потока в порядке, обратном порядку вызовов методов, и обрабатывается первым из них, в котором система находит подходящий обработчик. Аналогичная схема обработки исключений реализована в Java и в .NET.

Группы потоков. В сложных задачах, например, задачах моделирования, при большом числе разнородных потоков, возникает потребность в их структурировании и помощью концепции группы потоков – совокупности потоков, имеющей свое собственное имя, над потоками которой определены групповые операции. Наиболее удачно, с нашей точки зрения, группы потоков реализованы в Java (с помощью класса ThreadGroup ). Следует отметить также эффективную реализацию пулов потоков (ThreadPool) в .NET.

Локальные данные потока (thread-local storage - TLS) – данные, принадлежащие только определенному потоку и используемые только этим потоком. Необходимость в таких данных очевидна, так как многопоточность – весьма важный метод распараллеливания решения большой задачи, при котором каждый поток работает над решением порученной ему части. Все современные операционные системы и платформы разработки программ поддерживают концепцию локальных данных потока.

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

Тупики (deadlocks) и их предотвращение. Как и процессы, потоки могут взаимно блокировать друг друга (т.е. может создаться ситуация deadlock ), при их неаккуратном программировании.

- Модель много / много (many-to-many) – модель, допускающая отображение нескольких пользовательских потоков в несколько системных потоков. Такая модель позволяет ОС создавать большое число системных потоков. Характерным примером ОС, использующей подобную модель, является ОС Solaris, а также Windows NT / 2000 / XP / 2003 / 2008 / 7 с пакетом ThreadFiber.