Почему взаимодействие потоков проще чем взаимодействие процессов

Занятие 11. Взаимодействие потоков

· Основные принципы взаимодействия потоков

· Основные проблемы взаимодействия потоков. Проблема соревнований

Основные принципы взаимодействия потоков

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

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

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

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

Однако обойтись без реализации взаимодействия потоков невозможно по нескольким причинам:

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

Основные проблемы взаимодействия потоков. Проблема соревнований

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

Рассмотрим основные подходы к решению проблемы соревнований:

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

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

Рассмотрим свойства, которыми должна обладать критическая секция:

Остается ответить на далеко не простой вопрос: «Как нам заставить систему воспринимать несколько операций как одну единую операцию?»

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

Источник

Взаимодействие процессов и потоков

Синхронизация потоков

Рассмотрим простейшую программу, в которой несколько потоков увеличивают на 1 значение элементов общего массива. Так как начальные значения элементов массива 0, то в результате весь массив должен быть заполнен числами, соответствующими числу потоков:

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

несколько разных способов решения подобных проблем:

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

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

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

Источник

Почему взаимодействие потоков проще чем взаимодействие процессов

Итого, плюсы потоков:
— Меньшие накладные расходы
— Простота взаимодействия

Плюсы процессов:
— Лучшая надёжность и изолированность

Минусы обоих являются обратными к плюсам второго метода.

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

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

По началу неправильно прочитал вопрос: «Почему вместо процессов удобнее использовать потоки».

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

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

Переключение контекста потока происходит быстрее, чем контекста процесса.

Подытожу:
1. Соображения безопасности. При крэше одной вкладки не полетят все.
2.Между процессами изоляция более жесткая чем между потоками. То есть архитектурные соображения, сфига ли разным вкладкам друг к другу в гости лазить.
Это что касается хрома.

это у быдлокодеров при креше одного потока все остальные накрываются. у нормальных прогеров с этим проблем нет.

Источник

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

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

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

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

Многозадачность и параллелизм

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

Многозадачные системы на однопоточном процессоре создают иллюзию синхронного выполнения нескольких процессов. Пусть у нас есть три процесса. Если каждый из них работает время t1, t2 и t3, то общее время выполнения будет равно t1+ t2 + t3.

Если теперь мы разобьём каждую из задач на N частей, то общее время выполнения будет dt1*N+dt2*N+dt3*N+dts*N*N, где dts – это время, затрачиваемое на восстановление контекста выполнения задачи (на работу планировщика).

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

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

Для многоядерных систем всё яснее: если задача разбита на несколько потоков, то каждый из них может выполняться реально параллельно. То есть, если решать задачу в 4 потока вместо одного, то потенциально она станет работать в 4 раза быстрее. Очевидно, что где-то есть подвох…

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

Совместный доступ к ресурсам

К огда несколько потоков делают каждый своё дело, не разделяя память, то они могут сильно ускорить работу. Дополнительные издержки потребуются только для выделения ресурсов под эти потоки и для передачи им необходимых данных. Когда несколько потоков должны общаться друг с другом, передавать данные, обрабатывать один объект, то есть совместно обращаться к одному ресурсу (обычно это общий участок памяти), то возникают так называемые race conditions – состояния гонки – когда результат работы зависит от порядка доступа к ресурсам.

Например, нам нужно сложить два массива a и b одинаковой длины и поместить результат в массив c. Каждое значение c[i] зависит от a[i] и b[i] и не зависит от остальных. Мы можем разделить массивы на несколько участков, и каждый из потоков будет заниматься сложением только этих участков, не пересекаясь с остальными потоками. У них всех будут общие переменные a, b и c, но они будут всегда независимо обращаться только к отдельным областям памяти.

POSIX threads

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

В связи с этим, появилась необходимость в стандарте для потоков. Для UNIX-подобных операционных систем был принят стандарт IEEE POSIX 1003.1c (1995). Реализация библиотеки для работы с потоками в соответствии с этим стандартом и называется POSIX threads, или pthreads.

Источник

Взаимодействие и синхронизация потоков

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

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

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

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

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

Простейшей разновидностью семафоров являются двоичные семафоры, которые могут принимать только 2 возможных значения – 0 и 1. Именно на двоичных семафорах построены такие важные системные объекты, как критические секции и мьютексы (mutex, сокращение от mutual exclusion, т.е. взаимное исключение). Общим у них является то, что они применяются для синхронизации доступа потоков к разделяемым данным (общим файлам, общим структурам данных), а отличаются они тем, что первые используются для потоков внутри одно процесса, а вторые – для разных процессов. Как следствие, реализация мьютексов со стороны системы требует существенно больших затрат. Для прикладного программиста использование этих объектов практически не отличается, приходится лишь использовать разные системные вызовы.

Например, для использования критических секций (КС) достаточно лишь в создаваемом программном коде выделить начало и конец каждой такой секции. Для этого используются специальные системные вызовы, такие как EnterCriticalSection и LeaveCriticalSection в системах семейства Windows.

Когда выполнение кода потока доходит до системного вызова “Начало КС”, система отрабатывает этот вызов следующим образом:

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

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

Пусть в соответствии со своей внутренней логикой поток 1 должен начать работу сначала с файлом А, а потом (не завершив эту работу) – с файлом В. Пусть поток 2, наоборот, сначала начинает работу с файлом В, а потом – с файлом А. При этом возможна следующая последовательность действий:

Для борьбы с тупиковыми ситуациями было предложено множество методов. Видимо, наиболее интересным методом является полное игнорирование данной ситуации, что, впрочем, объясняется очень маленькой вероятностью возникновения тупика. Здесь работает хорошо известный принцип практической уверенности: очень маловероятное событие можно считать невозможным. Дело в том, что затраты на анализ и устранение ситуации взаимной блокировки могут быть достаточно большими, поэтому разработчики ОС должны сопоставить эти затраты с тем потенциальным вредом, который может принести возникновение данной ситуации.

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

статьи IT, теория программирования, потоки, лекции по программированию, лекции

Источник