Операционная система — многопоточность

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

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

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

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

Разница между процессом и потоком

SN	Процесс	Нить
1	Процесс тяжелый или ресурсоемкий.	Нить имеет малый вес и требует меньше ресурсов, чем процесс.
2	Процесс переключения требует взаимодействия с операционной системой.	Переключение потоков не требует взаимодействия с операционной системой.
3	В нескольких средах обработки каждый процесс выполняет один и тот же код, но имеет собственные ресурсы памяти и файлов.	Все потоки могут совместно использовать один и тот же набор открытых файлов, дочерних процессов.
4	Если один процесс заблокирован, то ни один другой процесс не может выполняться, пока первый процесс не будет разблокирован.	Пока один поток заблокирован и ожидает, второй поток в той же задаче может работать.
5	Несколько процессов без использования потоков используют больше ресурсов.	Многопоточные процессы используют меньше ресурсов.
6	В нескольких процессах каждый процесс работает независимо от других.	Один поток может читать, записывать или изменять данные другого потока.

Преимущества нити

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

Типы ниток

Потоки реализуются следующими двумя способами:

Потоки уровня пользователя — управляемые пользователем потоки.

Потоки уровня ядра — управляемые потоки операционной системы, работающие на ядре, ядре операционной системы.

Потоки уровня пользователя — управляемые пользователем потоки.

Потоки уровня ядра — управляемые потоки операционной системы, работающие на ядре, ядре операционной системы.

Потоки уровня пользователя

В этом случае ядро ​​управления потоками не знает о существовании потоков. Библиотека потоков содержит код для создания и уничтожения потоков, для передачи сообщений и данных между потоками, для планирования выполнения потоков и для сохранения и восстановления контекстов потоков. Приложение запускается с одного потока.

преимущества

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

Недостатки

• В типичной операционной системе большинство системных вызовов блокируются.
• Многопоточное приложение не может использовать преимущества многопроцессорной обработки.

Потоки уровня ядра

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

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

преимущества

• Ядро может одновременно планировать несколько потоков из одного процесса на несколько процессов.
• Если один поток в процессе заблокирован, ядро ​​может запланировать другой поток того же процесса.
• Сами подпрограммы ядра могут быть многопоточными.

Недостатки

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

Многопоточные модели

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

• Много ко многим отношениям.
• Много к одному отношения.
• Отношения один к одному.

Модель много ко многим

Модель «многие ко многим» мультиплексирует любое количество пользовательских потоков на равное или меньшее количество потоков ядра.

На следующей диаграмме показана модель многопоточности, при которой 6 потоков уровня пользователя мультиплексируются с 6 потоками уровня ядра. В этой модели разработчики могут создавать столько пользовательских потоков, сколько необходимо, и соответствующие потоки ядра могут работать параллельно на многопроцессорной машине. Эта модель обеспечивает наилучшую точность при параллельности, и когда поток выполняет системный вызов блокировки, ядро ​​может запланировать выполнение другого потока.

Много к одной модели

Модель «многие к одному» отображает множество потоков уровня пользователя в один поток уровня ядра. Управление потоками осуществляется в пространстве пользователя библиотекой потоков. Когда поток выполняет системный вызов блокировки, весь процесс будет заблокирован. Только один поток может одновременно обращаться к Ядру, поэтому несколько потоков не могут работать параллельно на многопроцессорных системах.

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

Модель один на один

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

Недостатком этой модели является то, что для создания пользовательского потока требуется соответствующий поток ядра. OS / 2, Windows NT и Windows 2000 используют модель отношений один к одному.

Операционные системы

• Современные операционные системы, Э. Таненбаум, 2002, СПб, Питер, 1040 стр., (в djvu 10.1Мбайт) подробнее>>
• Сетевые операционные системы Н. А. Олифер, В. Г. Олифер (в zip архиве 1.1Мбайт)
• Сетевые операционные системы Н. А. Олифер, В. Г. Олифер, 2001, СПб, Питер, 544 стр., (в djvu 6.3Мбайт) подробнее>>

4.1.1 Понятие процесса

Процесс (задача) — программа, находящаяся в режиме выполнения.

С каждым процессом связывается его адресное пространство, из которого он может читать и в которое он может писать данные.

Адресное пространство содержит:

данные к программе

С каждым процессом связывается набор регистров, например:

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

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

Некоторые поля таблицы:

Время начала процесса

Использованное процессорное время

Указатель на текстовый сегмент

Указатель на сегмент данных

Указатель на сегмент стека

4.1.2 Модель процесса

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

Рассмотрим схему с четырьмя работающими программами.

В каждый момент времени активен только один процесс

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

4.1.3 Создание процесса

Три основных события, приводящие к созданию процессов (вызов fork или CreateProcess):

Работающий процесс подает системный вызов на создание процесса

Запрос пользователя на создание процесса

Во всех случаях, активный текущий процесс посылает системный вызов на создание нового процесса.

В UNIX каждому процессу присваивается идентификатор процесса ( PID — Process IDentifier)

4.1.4 Завершение процесса

Четыре события, приводящие к остановке процесса (вызов exit или ExitProcess):

Плановое завершение (окончание выполнения)

Плановый выход по известной ошибке (например, отсутствие файла)

Выход по неисправимой ошибке (ошибка в программе)

Уничтожение другим процессом

Таким образом, приостановленный процесс состоит из собственного адресного пространства, обычно называемого образом памяти (core image), и компонентов таблицы процессов (в числе компонентов и его регистры).

4.1.5 Иерархия процессов

В UNIX системах заложена жесткая иерархия процессов. Каждый новый процесс созданный системным вызовом fork, является дочерним к предыдущему процессу. Дочернему процессу достаются от родительского переменные, регистры и т.п. После вызова fork, как только родительские данные скопированы, последующие изменения в одном из процессов не влияют на другой, но процессы помнят о том, кто является родительским.

В таком случае в UNIX существует и прародитель всех процессов — процесс init.

Дерево процессов для систем UNIX

4.1.6 Состояние процессов

Три состояния процесса:

Выполнение (занимает процессор)

Готовность (процесс временно приостановлен, чтобы позволить выполняться другому процессу)

Ожидание (процесс не может быть запущен по своим внутренним причинам, например, ожидая операции ввода/вывода)

Возможные переходы между состояниями.

1. Процесс блокируется, ожидая входных данных

2. Планировщик выбирает другой процесс

3. Планировщик выбирает этот процесс

4. Поступили входные данные

Переходы 2 и 3 вызываются планировщиком процессов операционной системы, так что сами процессы даже не знают о этих переходах. С точки зрения самих процессов есть два состояния выполнения и ожидания.

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

4.2 Потоки (нити, облегченный процесс)

4.2.1 Понятие потока

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

Сравнение многопоточной системы с однопоточной

Процессы и потоки Windows

Процессы и потоки Windows

Внутри каждого процесса могут выполняться одна или несколько потоков, и именно поток является базовой единицей выполнения в Windows. Выполнение потоков планируется системой на основе обычных факторов: наличие таких ресурсов, как CPU и физическая память, приоритеты, равнодоступность ресурсов и так далее. Начиная с версии NT4, в Windows поддерживается симметричная многопроцессорная обработка (Symmetric Multiprocessing, SMP), позволяющая распределять выполнение потоков между отдельными процессорами, установленными в системе.

С точки зрения программиста каждому процессу принадлежат ресурсы, представленные следующими компонентами:

• Одна или несколько потоков.

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

• Один или несколько сегментов кода, включая код DLL.

• Один или несколько сегментов данных, содержащих глобальные переменные.

• Строки, содержащие информацию об окружении, например, информацию о текущем пути доступа к файлам.

• Различного рода ресурсы, например, дескрипторы открытых файлов и другие кучи.

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

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

• Локальные области хранения потока (Thread Local Storage, SLT) — массивы указателей, используя которые каждый поток может создавать собственную уникальную информационную среду.

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

• Структура контекста, поддерживаемая ядром системы и содержащая значения машинных регистров.

На рис. 6.1 показан процесс с несколькими потоками. Рисунок является схематическим, поэтому на нем не указаны фактические адреса памяти и не соблюдены масштабы.

В данной главе показано, как работать с процессами, состоящими из единственного потока. О том, как использовать несколько потоков, рассказывается в главе 7.

Примечание

Рисунок 6.1 является высокоуровневым с точки зрения программиста представлением процесса. В действительности эта картина должна быть дополнена множеством технических деталей и особенностями реализации. Более подробную информацию заинтересованные читатели могут найти в книге Соломона (Solomon) и Руссиновича (Russinovich) Inside Windows 2000.

Процессы UNIX сопоставимы с процессами Windows, имеющими единственный поток.

Реализации UNIX недавно пополнились потоками POSIX Pthreads, которые в настоящее время используются почти повсеместно. В [40] потоки не обсуждаются; все рассмотрение основано на процессах.

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

Рис. 6.1. Процесс и его потоки

Читайте также

Процессы и потоки

Процессы и потоки В этой главе представлено описание процессов и потоков в QNX/ Neutrino, диспетчеризации, системы приоритетов, и дано понятие о реальном времени. Вы узнаете о состояниях потоков и алгоритмах диспетчеризации, которые применяются в QNX/ Neutrino, а также изучите

Процессы и потоки

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

2. Процессы и потоки

2. Процессы и потоки При внимательном чтении технической документации [8] и литературы по ОС QNX [1] отчетливо бросается в глаза, что тонкие детали создания и функционирования процессов и потоков описаны крайне поверхностно и на весьма некачественном уровне. Возможно, это

Потоки

Потоки Последующие расширения[14] POSIX специфицируют широкий спектр механизмов «легких процессов» — потоков (группа API pthread_*()). Техника потоков вводит новую парадигму программирования вместо уже ставших традиционными UNIX-методов. Это обстоятельство часто недооценивается.

Процессы, задачи, задания, группы активизации и потоки

Процессы, задачи, задания, группы активизации и потоки Как уже упоминалось, первоначально в AS/400 было определено три уровня работы. Самый низкий уровень, под MI, — задача. Процесс «живет» на уровне MI и построен на структуре задач SLIC. Поверх модели процессов MI OS/400 в качестве

10.4 ПОТОКИ

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

1.2. Процессы, потоки и общий доступ к информации

1.2. Процессы, потоки и общий доступ к информации В традиционной модели программирования Unix в системе могут одновременно выполняться несколько процессов, каждому из которых выделяется собственное адресное пространство. Это иллюстрирует рис. 1.1. Рис. 1.1. Совместное

Потоки

Потоки Хотя концепция процессов в системах Unix используется уже очень давно, возможность использовать несколько потоков внутри одного процесса появилась относительно недавно. Стандарт потоков Posix.1, называемый Pthreads, был принят в 1995 году. С точки зрения взаимодействия

38. Потоки

38. Потоки Язык C++ не обладает средствами для ввода/вывода. Ему это и не нужно; подобные средства легко и элегантно можно создать, применяя сам язык. Стандартная библиотека потокового ввода/вывода дает возможность осуществлять гибкий и эффективный с гарантией типа метод

7.3.1.2. Потоки

7.3.1.2. Потоки Потоки (streams) сетевого взаимодействия были разработаны Деннисом Ритчи для Unix Version 8 (1985). Их новая реализация называется STREAMS (именно так, в документации все буквы прописные). Впервые она стала доетупной в версии 3.0 System V Unix (1986). Средство STREAMS обеспечивало

7.3.1.2. Потоки

7.3.1.2. Потоки Потоки (streams) сетевого взаимодействия были разработаны Деннисом Ритчи для Unix Version 8 (1985). Их новая реализация называется STREAMS (именно так, в документации все буквы прописные). Впервые она стала доступной в версии 3.0 System V Unix (1986). Средство STREAMS обеспечивало

2.2.1.1 Потоки

2.2.1.1 Потоки Архитектуру INFORMIX-OnLine DS называют также многопотоковой. Для каждого клиента создается так называемый поток, или нить (thread). Поток — это подзадача, выполняемая в рамках одного из серверных процессов. В некоторых случаях для обслуживания одного клиентского

8.3 Файлы и Потоки

8.3 Файлы и Потоки Потоки обычно связаны с файлами. Библиотека потоков содает стандартный поток ввода cin, стандартный поток вывода cout и стандартный поток ошибок cerr. Программист может отрывать другие файлы и создавать для них

ГЛABA 6 Процессы, потоки и задания

ГЛABA 6 Процессы, потоки и задания B этой главе мы рассмотрим структуры данных и алгоритмы, связанные с процессами, потоками и заданиями в Microsoft Windows. B первом разделе основное внимание уделяется внутренним структурам данных, из которых состоит процесс. Bo втором разделе