Многопоточные приложения для.NET. Восемь простых правил разработки многопоточных приложений Многопоточные приложения
Преимущества:
- Простота разработки. Фактически, мы запускаем много копий однопоточного приложения и они работают независимо друг от друга. Можно не использовать никаких специфически многопоточных API и средств межпроцессного взаимодействия .
- Высокая надежность. Аварийное завершение любого из процессов никак не затрагивает остальные процессы.
- Хорошая переносимость. Приложение будет работать налюбой многозадачной ОС
- Высокая безопасность. Разные процессы приложения могут запускаться от имени разных пользователей. Таким образом можно реализовать принцип минимальных привилегий, когда каждый из процессов имеет лишь те права, которые необходимы ему для работы. Даже если в каком-то из процессов будет обнаружена ошибка, допускающая удаленное исполнение кода, взломщик сможет получить лишь уровень доступа, с которым исполнялся этот процесс.
Недостатки:
- Далеко не все прикладные задачи можно предоставлять таким образом. Например, эта архитектура годится для сервера, занимающегося раздачей статических HTMLстраниц, но совсем непригодна для сервера баз данных и многих серверов приложений.
- Создание и уничтожение процессов – дорогая операция, поэтому для многих задач такая архитектура неоптимальна.
В Unix-системах предпринимается целый комплекс мер для того, чтобы сделать создание процесса и запуск новой программы в процессе как можно более дешевыми операциями. Однако нужно понимать, что создание нити в рамках существующего процесса всегда будет дешевле, чем создание нового процесса.
Примеры: apache 1.x ( сервер HTTP )
Многопроцессные приложения, взаимодействующие через сокеты, трубы и очереди сообщений System V IPC
Перечисленные средства IPC ( Interprocess communication ) относятся к так называемым средствам гармонического межпроцессного взаимодействия. Онипозволяют организовать взаимодействие процессов и потоков без использования разделяемой памяти. Теоретики программирования очень любят эту архитектуру, потому что она практически исключает многие варианты ошибок соревнования.
Преимущества:
- Относительная простота разработки.
- Высокая надежность. Аварийное завершение одного из процессов приводит к закрытию трубы или сокета, а в случае очередей сообщений – к тому, что сообщения перестают поступать в очередь или извлекаться из нее. Остальные процессы приложения легко могут обнаружить эту ошибку и восстановиться после нее, возможно (но не обязательно) просто перезапустив отказавший процесс.
- Многие такие приложения (особенно основанные на использовании сокетов) легко переделываются для исполненияв распределенной среде, когда разные компоненты приложения исполняются на разных машинах.
- Хорошая переносимость. Приложение будет работать на большинстве многозадачных ОС, в том числе на старых Unix-системах.
- Высокая безопасность. Разные процессы приложения могут запускаться от имени разных пользователей. Таким образом можно реализовать принцип минимальных привилегий, когда каждый из процессов имеет лишь те права, которые необходимы ему для работы.
Даже если в каком-то из процессов будет обнаружена ошибка, допускающая удаленное исполнение кода, взломщик сможет получить лишь уровень доступа, с которым исполнялся этот процесс.
Недостатки:
- Не для всех прикладных задач такую архитектуру легко разработать и реализовать.
- Все перечисленные типы средств IPC предполагают последовательную передачу данных. Если необходим произвольный доступ к разделяемым данным, такая архитектура неудобна.
- Передача данных через трубу, сокет и очередь сообщений требует исполнения системных вызовов и двойного копирования данных – сначала из адресного пространства исходного процесса в адресное пространство ядра, затем из адресного пространства ядра в память целевого процесса . Это дорогие операции. При передаче больших объемов данных это может превратиться в серьезную проблему.
- В большинстве систем действуют ограничения на общее количество труб, сокетов и средств IPC. Так, в Solaris по умолчанию допускается не более 1024 открытых труб, сокетов и файлов на процесс (это обусловлено ограничениями системного вызова select). Архитектурное ограничение Solaris – 65536 труб, сокетов и файлов на процесс.
Ограничение на общее количество сокетов TCP/IP – не более 65536 на сетевой интерфейс (обусловлено форматом заголовков TCP). Очереди сообщений System V IPC размещаются вадресном пространствеядра, поэтому действуют жесткиеограничения на количество очередей в системе и на объем и количество одновременно находящихся в очередях сообщений.
- Создание и уничтожение процесса, а также переключение между процессами – дорогие операции. Не во всех случаях такая архитектура оптимальна.
Многопроцессные приложения, взаимодействующие через разделяемую память
В качестве разделяемой памяти может использоваться разделяемая память System V IPC и отображение файлов на память . Для синхронизации доступа можно использовать семафоры System V IPC , мутексы и семафоры POSIX , при отображении файлов на память – захват участков файла.
Преимущества:
- Эффективный произвольный доступ к разделяемым данным. Такая архитектура пригодна для реализации серверов баз данных.
- Высокая переносимость. Может быть перенесено налюбую операционную систему, поддерживающую или эмулирующую System V IPC .
- Относительно высокая безопасность. Разные процессыприложениямогут запускаться от имени разных пользователей. Таким образом можно реализовать принцип минимальных привилегий, когда каждый из процессов имеет лишь те права, которые необходимы ему для работы. Однако разделение уровней доступа не такое жесткое, как в ранее рассмотренных архитектурах.
Недостатки:
- Относительная сложность разработки. Ошибки при синхронизации доступа – так называемые ошибки соревнования – очень сложно обнаруживать при тестировании.
Это может привести к повышению общей стоимости разработки в 3–5 раз по сравнению с однопоточными или более простыми многозадачными архитектурами.
- Низкая надежность. Аварийное завершение любого из процессов приложения может оставить (и часто оставляет) разделяемую память в несогласованном состоянии.
Это часто приводит к аварийному завершению остальных задач приложения. Некоторые приложения, например Lotus Domino, специально убивают всесерверные процессы при аварийном завершении любого из них.
- Создание и уничтожение процесса и переключение между ними – дорогие операции.
Поэтому данная архитектура оптимальна не для всех приложений.
- При определенных обстоятельствах, использование разделяемой памяти может приводить к эскалации привилегий. Если в одном из процессов будет найдена ошибка, приводящая к удаленному исполнению кода, с высокой вероятностью взломщик сможет ее использовать для удаленного исполнения кода в других процессах приложения.
То есть, в худшем случае, взломщик может получить уровень доступа, соответствующий наивысшему из уровней доступа процессов приложения.
- Приложения, использующие разделяемую память, должны исполняться на одном физическом компьютереили, во всяком случае, на машинах, имеющих разделяемое ОЗУ. В действительности, это ограничение можно обойти, например используя отображенные на память разделяемые файлы, но это приводит к значительным накладным расходам
Фактически, данная архитектура сочетает недостатки многопроцессных и собственно многопоточных приложений. Тем не менее, ряд популярных приложений, разработанных в 80е и начале 90х, до того, как в Unix были стандартизованы многопоточные API , используют эту архитектуру. Это многие серверы баз данных, как коммерческие ( Oracle , DB2 , Lotus Domino), такисвободно распространяемые,современные версии Sendmail инекоторые другие почтовые серверы.
Собственно многопоточные приложения
Потоки или нити приложения исполняются в пределах одного процесса. Все адресное пространство процесса разделяется между потоками. На первый взгляд кажется, что это позволяет организовать взаимодействие между потоками вообще без каких-либо специальных API . В действительности, это не так – если несколько потоков работает с разделяемой структурой данных или системным ресурсом, и хотя бы один из потоков модифицирует эту структуру, то в некоторые моменты времени данные будут несогласованными.
Поэтому потоки должны использовать специальные средства для организации взаимодействия. Наиболее важные средства – это примитивы взаимоисключения (мутексы и блокировки чтения-записи). Используя эти примитивы, программист может добиться того, чтобы ни один поток не обращался к разделяемым ресурсам, пока они находятся в несогласованном состоянии (это и называется взаимоисключением). System V IPC , разделяются только те структуры, которые размещены в сегменте разделяемой памяти. Обычные переменные и размещаемые обычным образом динамические структуры данных свои укаждого изпроцессов). Ошибки придоступекразделяемым данным – ошибки соревнования – очень сложно обнаруживать при тестировании.
В целом можно сказать, что многопоточные приложения имеют почти те же преимущества и недостатки, что и многопроцессные приложения, использующие разделяемую память .
Однако стоимость исполнения многопоточного приложения ниже, а разработка такого приложения в некоторых отношениях проще, чем приложения, основанного наразделяемой памяти. Поэтому в последние годы многопоточные приложения становятся все более и более популярны.
Клэй Бреширс (Clay Breshears)
Введение
Методы реализации многопоточности, используемые специалистами Intel, включают в себя четыре основных этапа: анализ, разработка и реализация, отладка и настройка производительности. Именно такой подход используется для создания многопоточного приложения из последовательного программного кода. Работа с программными средствами в ходе выполнения первого, третьего и четвертого этапов освещена достаточно широко, в то время как информации по реализации второго шага явно недостаточно.
Вышло в свет немало книг, посвящённых параллельным алгоритмам и параллельным вычислениям. Тем не менее, в этих изданиях в основном раскрываются передача сообщений, системы с распределённой памятью или теоретические параллельные модели вычислений, порой неприменимые к реальным многоядерным платформам. Если вы готовы серьёзно заниматься многопоточным программированием, вам наверняка потребуются знания о разработке алгоритмов для этих моделей. Конечно, применение данных моделей достаточно ограничено, поэтому многим разработчикам ПО, возможно, так и придется реализовать их на практике.
Без преувеличения можно сказать, что разработка многопоточных приложений – в первую очередь творческое занятие, и лишь потом уже научная деятельность. Из этой статьи вы узнаете о восьми несложных правилах, которые помогут вам расширить базу практических методов параллельного программирования и повысить эффективность реализации поточных вычислений в своих приложениях.
Правило 1. Выделите операции, выполняемые в программном коде независимо друг от друга
Параллельная обработка применима лишь к тем операциям последовательного кода, которые выполняются независимо друг от друга. Неплохим примером того, как независимые друг от друга действия приводят к реальному единому результату, является строительство дома. В нём участвуют рабочие множества специальностей: плотники, электрики, штукатуры, сантехники, кровельщики, маляры, каменщики, озеленители и проч. Конечно, некоторые из них не могут начать работать до того, как другие закончат свою деятельность (например, кровельщики не приступят к работе, пока не будут построены стены, а маляры не станут красить эти стены, если они не оштукатурены). Но в целом можно сказать, что все люди, участвующие в строительстве, действуют независимо друг от друга.
Рассмотрим ещё один пример – рабочий цикл пункта проката DVD-дисков, в который приходят заказы на определённые фильмы. Заказы распределяются между работниками пункта, которые ищут эти фильмы на складе. Естественно, если один из работников возьмёт со склада диск, на котором записан фильм с участием Одри Хепбёрн, это никоим образом не затронет другого работника, ищущего очередной боевик с Арнольдом Шварценеггером, и уж тем более не повлияет на их коллегу, находящегося в поисках дисков с новым сезоном сериала «Друзья». В нашем примере мы считаем, что все проблемы, связанные с отсутствием фильмов на складе, были решены до того, как заказы поступили в пункт проката, а упаковка и отправка любого заказа не повлияет на обработку других.
В своей работе вы наверняка столкнётесь с вычислениями, обработка которых возможна лишь в определённой последовательности, а не параллельно, поскольку различные итерации или шаги цикла зависят друг от друга и должны выполняться в строгом порядке. Возьмем живой пример из дикой природы. Представьте себе беременную олениху. Поскольку вынашивание плода длится в среднем восемь месяцев, то, как ни крути, оленёнок не появится через месяц, даже если восемь олених забеременеют одновременно. Однако, восемь олених одновременно прекрасно бы справились со своей задачей, если запрячь их всех в сани Санта-Клауса.
Правило 2. Применяйте параллельность с низким уровнем детализации
Существует два подхода к параллельному разделению последовательного программного кода: «снизу-вверх» и «сверху-вниз». Сначала, на этапе анализа кода, определяются сегменты кода (так называемые «горячие» точки), на которые уходит значительная часть времени выполнения программы. Параллельное разделение этих сегментов кода (если оно возможно) обеспечит максимальный прирост производительности.
В подходе «снизу-вверх» реализуется многопоточная обработка «горячих» точек кода. Если параллельное разделение найденных точек невозможно, нужно исследовать стек вызовов приложения, чтобы определить другие сегменты, доступные для параллельного разделения и выполняющиеся достаточно долгое время. Предположим, вы работаете над приложением, предназначенным для сжатия графических изображений. Сжатие можно реализовать с помощью нескольких независимых параллельных потоков, обрабатывающих отдельные сегменты изображения. Однако даже если вам удалось реализовать многопоточность «горячих» точек, не пренебрегайте анализом стека вызовов, в результате которого можно найти доступные для параллельного разделения сегменты, находящиеся на более высоком уровне программного кода. Таким образом, вы сможете увеличить степень детализации параллельной обработки.
В подходе «сверху-вниз» анализируется работа программного кода, и выделяются его отдельные сегменты, выполнение которых приводит к завершению всей поставленной задачи. Если явная независимость основных сегментов кода отсутствует, проанализируйте их составляющие части для поиска независимых вычислений. Проанализировав программный код, вы сможете определить модули кода, на выполнение которых уходит больше всего процессорного времени. Рассмотрим реализацию поточной обработки в приложении, предназначенном для кодирования видео. Параллельная обработка может быть реализована на самом низком уровне – для независимых пикселей одного кадра, или на более высоком – для групп кадров, которые можно обработать независимо от других групп. Если приложение создаётся для одновременной обработки нескольких видеофайлов, параллельное разделение на таком уровне может оказаться ещё проще, а детализация будет иметь самую низкую степень.
Под степенью детализации параллельных вычислений понимается объём вычислений, которые необходимо выполнить перед синхронизацией между потоками. Другими словами, чем реже осуществляется синхронизация, тем ниже степень детализации. Поточные вычисления с высокой степень детализации могут привести к тому, что системные издержки, связанные с организацией потоков, превысят объём полезных вычислений, выполняемых этими потоками. Увеличение числа потоков при неизменном объёме вычислений усложняет процесс обработки. Многопоточность с низкой детализацией вызывает меньше системных задержек и имеет больший потенциал для масштабирования, которое может быть осуществлено с помощью организации дополнительных потоков. Для реализации параллельной обработки с низкой детализацией рекомендуется использовать подход «сверху-вниз» и организовывать потоки на высоком уровне стека вызовов.
Правило 3. Закладывайте в свой код возможности масштабирования, чтобы его производительность росла с ростом количества ядер.
Не так давно, помимо двухъядерных процессоров, на рынке появились четырёхъядерные. Более того, Intel уже объявила о создании процессора с 80 ядрами, способного выполнять триллион операций с плавающей точкой в секунду. Поскольку количество ядер в процессорах будет со временем только расти, ваш программный код должен иметь соответствующий потенциал для масштабируемости. Масштабируемость – параметр, по которому можно судить о способности приложения адекватно реагировать на такие изменения, как увеличение системных ресурсов (количество ядер, объём памяти, частота шины и проч.) или увеличение объёма данных. Учитывая, что количество ядер в процессорах будущего увеличится, создавайте масштабируемый код, производительность которого будет расти благодаря увеличению системных ресурсов.
Перефразируя один из законов Норткота Паркинсона (C. Northecote Parkinson), можно сказать, что «обработка данных занимает все доступные системные ресурсы». Это означает, что при увеличении вычислительных ресурсов (например, количества ядер), все они, вероятнее всего, будут использоваться для обработки данных. Вернёмся к приложению для сжатия видео, рассмотренному выше. Появление у процессора дополнительных ядер вряд ли скажется на размере обрабатываемых кадров – вместо этого увеличится число потоков, обрабатывающих кадр, что приведёт к уменьшению количества пикселей на поток. В результате, из-за организации дополнительных потоков, возрастет объем служебных данных, а степень детализации параллелизма снизится. Ещё одним более вероятным сценарием может стать увеличение размера или количества видеофайлов, которые нужно будет кодировать. В этом случае организация дополнительных потоков, которые будут обрабатывать более объёмные (или дополнительные) видеофайлы, позволит разделить весь объём работ непосредственно на том этапе, где произошло увеличение. В свою очередь, приложение с такими возможностями будет иметь высокий потенциал для масштабируемости.
Разработка и реализация параллельной обработки с использованием декомпозиции данных обеспечивает повышенную масштабируемость по сравнению с использованием функциональной декомпозиции. Количество независимых функций в программном коде чаще всего ограничено и не меняется в процессе выполнения приложения. Поскольку каждой независимой функции выделяется отдельный поток (и, соответственно, процессорное ядро), то с увеличением количества ядер дополнительно организуемые потоки не вызовут прироста производительности. Итак, модели параллельного разделения с декомпозицией данных обеспечат повышенный потенциал для масштабируемости приложения благодаря тому, что с увеличением количества процессорных ядер возрастёт объём обрабатываемых данных.
Даже если в программном коде организована поточная обработка независимых функций, вероятна возможность использования дополнительных потоков, запускаемых при увеличении входной нагрузки. Вернёмся к примеру со строительством дома, рассмотренному выше. Своеобразная цель строительства – завершить ограниченное количество независимых задач. Однако, если поступило указание возвести в два раза больше этажей, вам наверняка захочется нанять дополнительных рабочих некоторых специальностей (маляров, кровельщиков, сантехников и проч.). Следовательно, вам нужно разрабатывать приложения, которые могут адаптироваться под декомпозицию данных, возникающую в результате увеличения нагрузки. Если в вашем коде реализована функциональная декомпозиция, предусмотрите организацию дополнительных потоков при увеличении количества процессорных ядер.
Правило 4. Применяйте поточно-ориентированные библиотеки
Если для обработки данных в «горячих» точках кода может понадобиться какая-либо библиотека, обязательно подумайте об использовании готовых функций вместо собственного кода. Одним словом, не пытайтесь изобрести велосипед, разрабатывая сегменты кода, функции которых уже предусмотрены в оптимизированных процедурах из состава библиотек. Многие библиотеки, в том числе Intel® Math Kernel Library (Intel® MKL) и Intel® Integrated Performance Primitives (Intel® IPP), уже содержат многопоточные функции, оптимизированные под многоядерные процессоры.
Стоит заметить, что при использовании процедур из состава многопоточных библиотек необходимо убедиться, что вызов той или иной библиотеки не повлияет на нормальную работу потоков. То есть, если вызовы процедур осуществляются из двух различных потоков, в результате каждого вызова должны возвращаться правильные результаты. Если же процедуры обращаются к общим переменным библиотеки и обновляют их, возможно возникновение «гонки данных», которая пагубно отразится на достоверности результатов вычислений. Для корректной работы с потоками библиотечная процедура добавляется как новая (то есть не обновляет ничего, кроме локальных переменных) или синхронизируется для защиты доступа к общим ресурсам. Вывод: перед тем, как использовать в своём программном коде какую-либо библиотеку стороннего производителя, ознакомьтесь с приложенной к ней документацией, чтобы убедиться в ее корректной работе с потоками.
Правило 5. Используйте подходящую модель многопоточности
Предположим, для параллельного разделения всех подходящих сегментов кода функций из состава многопоточных библиотек явно недостаточно, и вам пришлось задуматься об организации потоков. Не спешите создавать собственную (громоздкую) структуру потоков, если библиотека OpenMP уже содержит все необходимые вам функциональные возможности.
Минусом явной многопоточности является невозможность точного управления потоками.
Если вам нужно только параллельное разделение ресурсоёмких циклов, либо дополнительная гибкость, которую дают явные потоки, стоит для вас на втором плане, то в данном случае смысла делать лишнюю работу не имеет. Чем сложнее реализация многопоточности, тем больше вероятность возникновения ошибок в коде и сложнее его последующая доработка.
Библиотека OpenMP ориентирована на декомпозицию данных и особенно хорошо подходит для поточной обработки циклов, работающих с большими объёмами информации. Несмотря на то, что к некоторым приложениям применима лишь декомпозиция данных, необходимо учесть и дополнительные требования (например, работодателя или заказчика), согласно которым использование OpenMP недопустимо и остаётся реализовывать многопоточность явными методами. В таком случае OpenMP можно использовать для предварительной организации потоков, чтобы оценить потенциальный прирост производительности, масштабируемость и примерные усилия, которые потребуются для последующего разделения программного кода методом явной многопоточности.
Правило 6. Результат работы программного кода не должен зависеть от последовательности выполнения параллельных потоков
Для последовательного программного кода достаточно просто определить выражение, которое будет выполняться после любого другого выражения. В многопоточном коде порядок выполнения потоков не определён и зависит от указаний планировщика операционной системы. Строго говоря, практически невозможно предугадать последовательность потоков, запускаемых для выполнения какой-либо операции, или определить, какой поток будет запущен планировщиком в последующий момент. Прогнозирование главным образом используется для снижения времени задержки при выполнении приложения, особенно при работе на платформе с процессором, количество ядер которого меньше числа организованных потоков. Если какой-то поток заблокирован из-за того, что ему требуется доступ к области, не записанной в кэш-память, или из-за необходимости выполнить запрос на операцию ввода/вывода, планировщик приостановит его и запустит поток, готовый к запуску.
Непосредственным результатом неопределённости в планировании выполнения потоков являются ситуации с возникновением «гонки данных». Предположение о том, что какой-то поток изменит значение общей переменной до того, как другой поток считает это значение, может оказаться ошибочным. При удачном стечении обстоятельств порядок выполнения потоков для конкретной платформы останется одним и тем же при всех запусках приложения. Однако мельчайшие изменения в состоянии системы (например, расположение данных на жёстком диске, быстродействие памяти или даже отклонение от номинала частоты переменного тока сети питания) способны спровоцировать иной порядок выполнения потоков. Таким образом, для программного кода, работающего корректно лишь с определённой последовательностью потоков, вероятны проблемы, связанные с ситуациями «гонки данных» и взаимными блокировками.
С точки зрения прироста производительности предпочтительнее не ограничивать порядок выполнения потоков. Строгая последовательность выполнения потоков допускается лишь в случае крайней необходимости, определяемой по заранее установленному критерию. В случае возникновения таких обстоятельств потоки будут запускаться в порядке, заданном предусмотренными механизмами синхронизации. Для примера представим двух друзей, читающих газету, которая разложена на столе. Во-первых, они могут читать с разной скоростью, во-вторых, они могут читать разные статьи. И здесь неважно, кто прочтёт разворот газеты первым – ему в любом случае придётся подождать своего приятеля, прежде чем перевернуть страницу. При этом не ставится никаких ограничений по времени и порядку чтения статей – приятели читают с любой скоростью, а синхронизация между ними наступает непосредственно при переворачивании страницы.
Правило 7. Используйте локальное хранение потоков. При необходимости назначайте блокировки на отдельные области данных
Синхронизация неизбежно увеличивает нагрузку на систему, что ни коим образом не ускоряет процесс получения результатов параллельных вычислений, однако обеспечивает их правильность. Да, синхронизация необходима, но ей нельзя злоупотреблять. Для минимизации синхронизации применяется локальное хранение потоков или выделенные области памяти (например, элементы массива, помеченные идентификаторами соответствующих потоков).
Необходимость совместного использования временных переменных разными потоками возникает достаточно редко. Такие переменные необходимо объявлять или выделять локально каждому потоку. Переменные, значения которых являются промежуточными результатами выполнения потоков, также должны быть объявлены локальными для соответствующих потоков. Для суммирования этих промежуточных результатов в какой-то общей области памяти потребуется синхронизация. Чтобы минимизировать возможные нагрузки на систему, предпочтительно обновлять эту общую область как можно реже. Для методов явной многопоточности предусмотрены прикладные программные интерфейсы локального хранения потоков, обеспечивающие целостность локальных данных с начала выполнения одного многопоточного сегмента кода до начала выполнения следующего сегмента (или в процессе обработки одного вызова многопоточной функции до следующего выполнения этой же функции).
Если локальное хранение потоков невозможно, доступ к общим ресурсам синхронизируется с помощью различных объектов, например, блокировок. При этом важно правильно назначить блокировки конкретным блокам данных, что проще всего сделать, если количество блокировок равно количеству блоков данных. Единый механизм блокировки, синхронизирующий доступ к нескольким областям памяти, применяется только тогда, когда все эти области постоянно находятся в одном и том же критическом разделе программного кода.
Как поступить, если возникла необходимость синхронизировать доступ к большому объёму данных, например, к массиву, состоящему из 10000 элементов? Организовать единственную блокировку для всего массива – значит наверняка создать узкое место в приложении. Неужели придётся организовывать блокировку для каждого элемента в отдельности? Тогда, даже если к данным будут обращаться 32 или 64 параллельных потока, придётся предотвращать конфликты доступа к довольно большой области памяти, причём вероятность возникновения таких конфликтов – 1%. К счастью, существует своеобразная золотая середина, так называемые «блокировки по модулю». Если используется N блокировок по модулю, каждая из них будет синхронизировать доступ к N-й части общей области данных. Например, если организовано две таких блокировки, одна из них будет предотвращать доступ к чётным элементам массива, а вторая – к нечётным. В таком случае, потоки, обращаясь к необходимому элементу, определяют его чётность и устанавливают соответствующую блокировку. Количество блокировок по модулю выбирается с учётом количества потоков и вероятности одновременного обращения нескольких потоков к одной и той же области памяти.
Заметим, что для синхронизации доступа к одной области памяти не допускается одновременное использование нескольких механизмов блокировки. Вспомним закон Сегала: «Человек, имеющий одни часы, твердо знает, который час. Человек, имеющий несколько часов, ни в чём не уверен». Предположим, что доступ к переменной контролируют две различные блокировки. В этом случае первой блокировкой может воспользоваться один сегмент кода, а второй – другой сегмент. Тогда потоки, выполняющие эти сегменты, окажутся в ситуации гонки за общие данные, к которым они одновременно обращаются.
Правило 8. Измените программный алгоритм, если это требуется для реализации многопоточности
Критерием оценки производительности приложений, как последовательных, так и параллельных, является время выполнения. В качестве оценки алгоритма подходит асимптотический порядок. По этому теоретическому показателю практически всегда можно оценить производительность приложения. То есть, при всех прочих равных условиях, приложение со степенью роста O(n log n) (быстрая сортировка), будет работать быстрее приложения со степенью роста O(n2) (выборочная сортировка), хотя результаты работы этих приложений одинаковы.
Чем лучше асимптотический порядок выполнения, тем быстрее выполняется параллельное приложение. Однако даже самый производительный последовательный алгоритм не всегда можно будет разделить на параллельные потоки. Если «горячую» точку программы слишком сложно разделить, и на более высоком уровне стека вызовов этой «горячей» точки тоже нет возможности реализовать многопоточность, следует сначала задуматься о применении иного последовательного алгоритма, более простого для разделения по сравнению с исходным. Безусловно, для подготовки программного кода к поточной обработке существуют и иные способы.
В качестве иллюстрации последнего утверждения рассмотрим умножение двух квадратных матриц. Алгоритм Штрассена имеет один из лучших асимптотических порядков выполнения: O(n2.81), который намного лучше, чем порядок O(n3) алгоритма с обычным тройным вложенным циклом. Согласно алгоритму Штрассена, каждая матрица делится на четыре подматрицы, после чего производится семь рекурсивных вызовов для перемножения n/2 × n/2 подматриц. Для распараллеливания рекурсивных вызовов можно создать новый поток, который последовательно выполнит семь независимых перемножений подматриц, пока они не достигнут заданного размера. В таком случае количество потоков будет экспоненциально возрастать, а степень детализации вычислений, выполняемых каждым вновь образованным потоком, будет повышаться с уменьшением размера подматриц. Рассмотрим другой вариант – организацию пула из семи потоков, работающих одновременно и выполняющих по одному перемножению подматриц. По завершению работы пула потоков происходит рекурсивный вызов метода Штрассена для умножения подматриц (как и в последовательной версии программного кода). Если в системе, выполняющей такую программу, будет больше восьми процессорных ядер, часть из них будет простаивать.
Алгоритм перемножения матриц гораздо проще подвергать параллельному разделению с помощью тройного вложенного цикла. В этом случае применяется декомпозиция данных, при которой матрицы делятся на строки, столбцы или подматрицы, а каждый из потоков выполняет определённые вычисления. Реализация такого алгоритма осуществляется с помощью прагм OpenMP, вставляемых на каком-либо уровне цикла, или явной организацией потоков, выполняющих деление матриц. Для реализации этого более простого последовательного алгоритма потребуется гораздо меньше доработок в программном коде, по сравнению с реализацией многопоточного алгоритма Штрассена.
Итак, теперь вы знаете восемь несложных правил эффективного преобразования последовательного программного кода в параллельный. Следуя этим правилам, вы значительно быстрее создадите многопоточные решения, которые будут обладать повышенной надёжностью, оптимальной производительностью и меньшим количеством узких мест.
Чтобы вернуться на web-страницу учебных курсов по многопоточному программированию, перейдите по
Какая тема вызывает больше всего вопросов и затруднений у начинающих? Когда я спросила об этом преподавателя и Java-программиста Александра Пряхина, он сразу ответил: «Многопоточность». Спасибо ему за идею и помощь в подготовке этой статьи!
Мы заглянем во внутренний мир приложения и его процессов, разберёмся, в чём суть многопоточности, когда она полезна и как её реализовать - на примере Java. Если учите другой язык ООП, не огорчайтесь: базовые принципы одни и те же.
О потоках и их истоках
Чтобы понять многопоточность, сначала вникнем, что такое процесс. Процесс – это часть виртуальной памяти и ресурсов, которую ОС выделяет для выполнения программы. Если открыть несколько экземпляров одного приложения, под каждый система выделит по процессу. В современных браузерах за каждую вкладку может отвечать отдельный процесс.
Вы наверняка сталкивались с «Диспетчером задач» Windows (в Linux это - «Системный монитор») и знаете, что лишние запущенные процессы грузят систему, а самые «тяжёлые» из них часто зависают, так что их приходится завершать принудительно.
Но пользователи любят многозадачность: хлебом не корми - дай открыть с десяток окон и попрыгать туда-сюда. Налицо дилемма: нужно обеспечить одновременную работу приложений и при этом снизить нагрузку на систему, чтобы она не тормозила. Допустим, «железу» не угнаться за потребностями владельцев - нужно решать вопрос на программном уровне.
Мы хотим, чтобы в единицу времени процессор успевал выполнить больше команд и обработать больше данных. То есть нам надо уместить в каждом кванте времени больше выполненного кода. Представьте единицу выполнения кода в виде объекта - это и есть поток.
К сложному делу легче подступиться, если разбить его на несколько простых. Так и при работе с памятью: «тяжёлый» процесс делят на потоки, которые занимают меньше ресурсов и скорее доносят код до вычислителя (как именно - см. ниже).
У каждого приложения есть как минимум один процесс, а у каждого процесса - минимум один поток, который называют главным и из которого при необходимости запускают новые.
Разница между потоками и процессами
Потоки используют память, выделенную под процесс, а процессы требуют себе отдельное место в памяти. Поэтому потоки создаются и завершаются быстрее: системе не нужно каждый раз выделять им новое адресное пространство, а потом высвобождать его.
Процессы работают каждый со своими данными - обмениваться чем-то они могут только через механизм межпроцессного взаимодействия. Потоки обращаются к данным и ресурсам друг друга напрямую: что изменил один - сразу доступно всем. Поток может контролировать «собратьев» по процессу, в то время как процесс контролирует исключительно своих «дочек». Поэтому переключаться между потоками быстрее и коммуникация между ними организована проще.
Какой отсюда вывод? Если вам нужно как можно быстрее обработать большой объём данных, разбейте его на куски, которые можно обрабатывать отдельными потоками, а затем соберите результат воедино. Это лучше, чем плодить жадные до ресурсов процессы.
Но почему такое популярное приложение как Firefox идёт по пути создания нескольких процессов? Потому что именно для браузера изолированная работа вкладок - это надёжно и гибко. Если с одним процессом что-то не так, не обязательно завершать программу целиком - есть возможность сохранить хотя бы часть данных.
Что такое многопоточность
Вот мы и подошли к главному. Многопоточность - это когда процесс приложения разбит на потоки, которые параллельно - в одну единицу времени - обрабатываются процессором.
Вычислительная нагрузка распределяется между двумя или более ядрами, так что интерфейс и другие компоненты программы не замедляют работу друг друга.
Многопоточные приложения можно запускать и на одноядерных процессорах, но тогда потоки выполняются по очереди: первый поработал, его состояние сохранили - дали поработать второму, сохранили - вернулись к первому или запустили третий, и т.д.
Занятые люди жалуются, что у них всего две руки. Процессы и программы могут иметь столько рук, сколько нужно для скорейшего выполнения задачи.
Жди сигнала: синхронизация в многопоточных приложениях
Представьте, что несколько потоков пытаются одновременно изменить одну и ту же область данных. Чьи изменения будут в итоге приняты, а чьи - отменены? Чтобы работа с общими ресурсами не приводила к путанице, потокам нужно координировать свои действия. Для этого они обмениваются информацией с помощью сигналов. Каждый поток сообщает другим, что он сейчас делает и каких изменений ждать. Так данные всех потоков о текущем состоянии ресурсов синхронизируются.
Основные средства синхронизации
Взаимоисключение (mutual exclusion, сокращённо - mutex) - «флажок», переходящий к потоку, который в данный момент имеет право работать с общими ресурсами. Исключает доступ остальных потоков к занятому участку памяти. Мьютексов в приложении может быть несколько, и они могут разделяться между процессами. Есть подвох: mutex заставляет приложение каждый раз обращаться к ядру операционной системы, что накладно.
Семафор - позволяет вам ограничить число потоков, имеющих доступ к ресурсу в конкретный момент. Так вы снизите нагрузку на процессор при выполнении кода, где есть узкие места. Проблема в том, что оптимальное число потоков зависит от машины пользователя.
Событие - вы определяете условие, при наступлении которого управление передаётся нужному потоку. Данными о событиях потоки обмениваются, чтобы развивать и логически продолжать действия друг друга. Один получил данные, другой проверил их корректность, третий - сохранил на жёсткий диск. События различаются по способу отмены сигнала о них. Если нужно уведомить о событии несколько потоков, для остановки сигнала придётся вручную ставить функцию отмены. Если же целевой поток только один, можно создать событие с автоматическим сбросом. Оно само остановит сигнал, после того как он дойдёт до потока. Для гибкого управления потоками события можно выстраивать в очередь.
Критическая секция - более сложный механизм, который объединяет в себе счётчик цикла и семафор. Счётчик позволяет отложить запуск семафора на нужное время. Преимущество в том, что ядро задействуется лишь в случае, если секция занята и нужно включать семафор. В остальное время поток выполняется в пользовательском режиме. Увы, секцию можно использовать только внутри одного процесса.
Как реализовать многопоточность в Java
За работу с потоками в Java отвечает класс Thread. Создать новый поток для выполнения задачи - значит создать экземпляр класса Thread и связать его с нужным кодом. Сделать это можно двумя путями:
образовать от Thread подкласс;
имплементировать в своём классе интерфейс Runnable, после чего передавать экземпляры класса в конструктор Thread.
Пока мы не будем затрагивать тему тупиковых ситуаций (deadlock"ов), когда потоки блокируют работу друг друга и зависают - оставим это для следующей статьи. А сейчас перейдём к практике.
Пример многопоточности в Java: пинг-понг мьютексами
Если вы думаете, что сейчас будет что-то страшное - выдохните. Работу с объектами синхронизации мы рассмотрим почти в игровой форме: два потока будут перебрасываться mutex"ом. Но по сути вы увидите реальное приложение, где в один момент времени только один поток может обрабатывать общедоступные данные.
Сначала создадим класс, наследующий свойства уже известного нам Thread, и напишем метод «удара по мячу» (kickBall):
Public class PingPongThread extends Thread{ PingPongThread(String name){ this.setName(name); // переопределяем имя потока } @Override public void run() { Ball ball = Ball.getBall(); while(ball.isInGame()){ kickBall(ball); } } private void kickBall(Ball ball) { if(!ball.getSide().equals(getName())){ ball.kick(getName()); } } }
Теперь позаботимся о мячике. Будет он у нас не простой, а памятливый: чтоб мог рассказать, кто по нему ударил, с какой стороны и сколько раз. Для этого используем mutex: он будет собирать информацию о работе каждого из потоков - это позволит изолированным потокам общаться друг с другом. После 15-го удара выведем мяч из игры, чтоб его сильно не травмировать.
Public class Ball { private int kicks = 0; private static Ball instance = new Ball(); private String side = ""; private Ball(){} static Ball getBall(){ return instance; } synchronized void kick(String playername){ kicks++; side = playername; System.out.println(kicks + " " + side); } String getSide(){ return side; } boolean isInGame(){ return (kicks < 15); } }
А теперь на сцену выходят два потока-игрока. Назовём их, не мудрствуя лукаво, Пинг и Понг:
Public class PingPongGame { PingPongThread player1 = new PingPongThread("Ping"); PingPongThread player2 = new PingPongThread("Pong"); Ball ball; PingPongGame(){ ball = Ball.getBall(); } void startGame() throws InterruptedException { player1.start(); player2.start(); } }
«Полный стадион народа - время начинать матч». Объявим об открытии встречи официально - в главном классе приложения:
Public class PingPong { public static void main(String args) throws InterruptedException { PingPongGame game = new PingPongGame(); game.startGame(); } }
Как видите, ничего зубодробительного здесь нет. Это пока только введение в многопоточность, но вы уже представляете, как это работает, и можете экспериментировать - ограничивать длительность игры не числом ударов, а по времени, например. Мы ещё вернёмся к теме многопоточности - рассмотрим пакет java.util.concurrent, библиотеку Akka и механизм volatile. А еще поговорим о реализации многопоточности на Python.
Пример посторения простого многопоточного приложения.
Рожден о причине большого числа вопросов о построении многопоточных приложений в Delphi.
Цель данного примера - продемонстрировать как правильно строить многопоточное приложение, с выносом длительной работы в отдельный поток. И как в таком приложении обеспечить взаимодействие основного потока с рабчим для передачи данных из формы (визуальных компонентов) в поток и обратно.
Пример не прретендует на полноту, он лишь демонстрирует наиболее простые способы взаимодействия потоков. Позволяя пользователю "быстренько слепить" (кто бы знал как я этого не люблю) правильно работающее многопоточное приложение.
В нем все подробно (на мой взгляд) прокоментированно, но, если будут вопросы, задавайте.
Но еще раз предостерегаю: Потоки - дело не простое
. Если Вы не представляете как все это работает, то есть огромная опасность что часто у Вас все будет работать нормально, а иногда программа будет вести себя более чем странно. Поведение неправильно написанной многопотчной программы очень сильно зависит от большого кол-ва факторов, которые порою невозможно воспроизвести при отладке.
Итак пример. Для удобства поместил и код, и прикрепил архив с кодом модуля и формы
unit ExThreadForm;
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls;
// константы используемые при передаче данных из потока в форму с помощью
// отсылки оконных сообщений
const
WM_USER_SendMessageMetod = WM_USER+10;
WM_USER_PostMessageMetod = WM_USER+11;
type
// описание класса потока, потомка от tThread
tMyThread = class(tThread)
private
SyncDataN:Integer;
SyncDataS:String;
procedure SyncMetod1;
protected
procedure Execute; override;
public
Param1:String;
Param2:Integer;
Param3:Boolean;
Stopped:Boolean;
LastRandom:Integer;
IterationNo:Integer;
ResultList:tStringList;
Constructor Create (aParam1:String);
destructor Destroy; override;
end;
// описание класса использующей поток формы
TForm1 = class(TForm)
Label1: TLabel;
Memo1: TMemo;
btnStart: TButton;
btnStop: TButton;
Edit1: TEdit;
Edit2: TEdit;
CheckBox1: TCheckBox;
Label2: TLabel;
Label3: TLabel;
Label4: TLabel;
procedure btnStartClick(Sender: TObject);
procedure btnStopClick(Sender: TObject);
private
{ Private declarations }
MyThread:tMyThread;
procedure EventMyThreadOnTerminate (Sender:tObject);
procedure EventOnSendMessageMetod (var Msg: TMessage);message WM_USER_SendMessageMetod;
procedure EventOnPostMessageMetod (var Msg: TMessage); message WM_USER_PostMessageMetod;
Public
{ Public declarations }
end;
var
Form1: TForm1;
{
Stopped - демонстрирует передачу данных от формы к потоку.
Дополнительной синхронизации не требует, поскольку является простым
однословным типом, и пишется только одним потоком.
}
procedure TForm1.btnStartClick(Sender: TObject);
begin
Randomize(); // обеспечение случайнсти в последовательности по Random() - к потоком отношения не имеет
// Создание экземпляра объекта потока, с передачей ему входного параметра
{
ВНИМАНИЕ!
Конструктор потока написан таким образом что поток создается
приостановленным, поскольку это позволяет:
1. Контролировать момент его запуска. Это почти всегда удобнее, т.к.
позволяет еще до запуска настроить поток, передать ему входные
параметры, и т.п.
2. Т.к. ссылка на созданный объект будет сохранена в поле формы, то
после самоуничтожения потока (см.ниже) которое при запущенном потоке
может произойти в любой момент, эта ссылка станет недействительной.
}
MyThread:= tMyThread.Create(Form1.Edit1.Text);
// Однако, поскольку поток создан приостановленным, то при любых ошибках
// во время его инициализации (до запуска), мы должны его сами уничтожить
// для чегу используем try / except блок
try
// Назначение обработчика завершения потока в котором будем принимать
// результаты работы потока, и "затирать" ссылку на него
MyThread.OnTerminate:= EventMyThreadOnTerminate;
// Поскольку результаты будем забирать в OnTerminate, т.е. до самоуничтожения
// потока то снимем с себя заботы по его уничтожению
MyThread.FreeOnTerminate:= True;
// Пример передачи входных параметров через поля объекта-потока, в точке
// создания экземпляра, когда он еще не запущен.
// Лично я, предпочитаю делать это через параметры переопределяемого
// конструктора (tMyThread.Create)
MyThread.Param2:= StrToInt(Form1.Edit2.Text);
MyThread.Stopped:= False; // своего рода тоже параметр, но меняющийся во
// время работы потока
except
// поскольку поток еще не запущен и не сможет самоуничтожиться, уничтожим его "вручную"
FreeAndNil(MyThread);
// а дальше пусть исключительная ситуация обрабатывается обычным порядком
raise;
end;
// Поскольку объект потока успешно создан и настроен, настало время запустить его
MyThread.Resume;
ShowMessage("Поток запущен");
end;
procedure TForm1.btnStopClick(Sender: TObject);
begin
// Если экземпляр потока еще существует, то попросим его остановиться
// Причем, именно "попросим". "Заставить" в принципе тоже можем, но это будет
// исключительно аварийный вариант, требующий четкого понимания всей этой
// потоковой кухни. Поэтому, здесь не рассматривается.
if Assigned(MyThread) then
MyThread.Stopped:= True
else
ShowMessage("Поток не запущен!");
end;
procedure TForm1.EventOnSendMessageMetod(var Msg: TMessage);
begin
// метод обработки синхронного сообщения
// в WParam адрес объекта tMyThread, в LParam тек.значение LastRandom потока
with tMyThread(Msg.WParam) do begin
Form1.Label3.Caption:= Format("%d %d %d",);
end;
end;
procedure TForm1.EventOnPostMessageMetod(var Msg: TMessage);
begin
// метод обработки асинхронного сообщения
// в WParam тек.значение IterationNo, в LParam тек.значение LastRandom потока
Form1.Label4.Caption:= Format("%d %d",);
end;
procedure TForm1.EventMyThreadOnTerminate (Sender:tObject);
begin
// ВАЖНО!
// Метот обработки события OnTerminate всегда вызывается в контексте основного
// потока - это гарантируется реализацией tThread. Поэтому, в нем можно свободно
// использовать любые свойства и методы любых объектов
// На всякий случай, убедимся что экземпляр объекта еще существует
if not Assigned(MyThread) then Exit; // если его нет, то и делать нечего
// получение результатов работы потока экземпляра объекта потока
Form1.Memo1.Lines.Add(Format("Поток завершился с результатом %d",));
Form1.Memo1.Lines.AddStrings((Sender as tMyThread).ResultList);
// Уничтожение ссылки на экземпляр объекта потока.
// Поскольку поток у нас самоуничтожающийся (FreeOnTerminate:= True)
// то после завершения обрабтчика OnTerminate, экземпляр объекта-потока будет
// уничтожен (Free), и все ссылки на него станут недействительными.
// Что бы случайно не напороться на такую ссылку, затрем MyThread
// Еще раз замечу - не уничтожим объект, а только затрем ссылку. Объект
// уничтожится сам!
MyThread:= Nil;
end;
constructor tMyThread.Create (aParam1:String);
begin
// Создаем экземпляр ПРИОСТАНОВЛЕННОГО потока (см.коментарий при создании экземпляра)
inherited Create(True);
// Создание внутренних объектов (если необходимо)
ResultList:= tStringList.Create;
// Получение исходных данных.
// Копирование входных данных переданных через параметр
Param1:= aParam1;
// Пример получения входных данных из VCL-компонентов в конструкторе объекта-потока
// Такое в данном случае допустимо, поскольку конструктор вызывается в контексте
// основного потока. Следовательно, здесь можно обращаться к VCL-компонентам.
// Но, я такого не люблю, поскольку считаю что плохо когда поток знает что-то
// о какой-то там форме. Но, чего не сделаешь для демонстрации.
Param3:= Form1.CheckBox1.Checked;
end;
destructor tMyThread.Destroy;
begin
// уничтожение внутренних объектов
FreeAndNil(ResultList);
// уничтожение базового tThread
inherited;
end;
procedure tMyThread.Execute;
var
t:Cardinal;
s:String;
begin
IterationNo:= 0; // счетчик результатов (номер цикла)
// В моем примере тело потока представляет собой цикл, который завершается
// либо по внешней "просьбе" завершиться передаваемый через изменяемый параметр Stopped,
// либо просто совершив 5 циклов
// Мне приятнее такое записывать через "вечный" цикл.
While True do begin
Inc(IterationNo); // очередной номер цикла
LastRandom:= Random(1000); // слючайное число - для демонстрации передачи параметров от потока в форму
T:= Random(5)+1; // время на которое будем засыпать если нас не завершат
// Тупая работа (зависящая от входного параметра)
if not Param3 then
Inc(Param2)
else
Dec(Param2);
// Сформируем промежуточный результат
s:= Format("%s %5d %s %d %d",
);
// Добавим промежуточный результат к списку резуольтатов
ResultList.Add(s);
//// Примеры передачи промежуточного результата на форму
//// Передача через синхронизируемый метод - классический способ
//// Недостатки:
//// - синхронизируемый метод - это обычно метод класса потока (для доступа
//// к полям объекта-потока), но, для доступа к полям формы, он должен
//// "знать" про нее и ее поля (объекты), что обычно не очень хорошо с
//// точки зрения организации программы.
//// - текущий поток будет приостановлен до завершения выполнения
//// синхронизированного метода.
//// Достоинства:
//// - стандартность и универсальность
//// - в синхронизированном методе можно пользоваться
//// всеми полями объекта-потока.
// сначала, если необходимо, надо сохранить передаваемые данные в
// специальных полях объекта объекта.
SyncDataN:= IterationNo;
SyncDataS:= "Sync"+s;
// и затем обеспечить синхронизированный вызов метода
Synchronize(SyncMetod1);
//// Передача через синхронную отсылку сообщения (SendMessage)
//// в этом случае, данные можно передать как через параметры сообщения (LastRandom),
//// так и через поля объекта, передав в параметре сообщения адрес экземпляра
//// объекта-потока - Integer(Self).
//// Недостатки:
//// - поток должен знать handle окна формы
//// - как и при Synchronize, текущий поток будет приостановлен до
//// завершения обработки сообщения основным потоком
//// - требует существенных затрат процессорного времени на каждый вызов
//// (на переключение потоков) поэтому нежелателен очень частый вызов
//// Достоинства:
//// - как и при Synchronize, при обработке сообщения можно пользоваться
//// всеми полями объекта-потока (если конечно был передан его адрес)
//// запуска потока.
SendMessage(Form1.Handle,WM_USER_SendMessageMetod,Integer(Self),LastRandom);
//// Передача через асинхронную отсылку сообщения (PostMessage)
//// Поскольку в этом случае к моменту получения сообщения основным потоком,
//// посылающий поток может уже завершиться, передача адреса экземпляра
//// объекта-потока недопустима!
//// Недостатки:
//// - поток должен знать handle окна формы;
//// - из-за асинхронности, передача данных возможна только через параметры
//// сообщения, что существенно усложняет передачу данных имеющих размер
//// более двух машинныхх слов. Удобно применять для передачи Integer и т.п.
//// Достоинства:
//// - в отличие от предыдущих методов, текущий поток НЕ будет
//// приостановлен, а сразу же продолжит свое выполнение
//// - в отличии от синхронизированного вызова, обработчиком сообщения
//// является метод формы, который должен иметь знания об объекте-потоке,
//// или вовсе ничего не знать о потоке, если данные передаеются только
//// через параметры сообщения. Т.е., поток может ничего не знать о форме
//// вообще - только ее Handle, который может быть передан как параметр до
//// запуска потока.
PostMessage(Form1.Handle,WM_USER_PostMessageMetod,IterationNo,LastRandom);
//// Проверка возможного завершения
// Проверка завершения по параметру
if Stopped then Break;
// Проверка завершения по случаю
if IterationNo >= 10 then Break;
Sleep(t*1000); // Засыпаем на t секунд
end;
end;
procedure tMyThread.SyncMetod1;
begin
// этот метод вызывается посредством метода Synchronize.
// Т.е., не смотря на то что он является методом потока tMyThread,
// он выполняется в контексте основного потока приложения.
// Следовательно, ему все можно, ну или почти все:)
// Но помним, здесь не стоит долго "возиться"
// Переданные параметры, мы можем извлечь из специальных поле, куда мы их
// сохранили перед вызовом.
Form1.Label1.Caption:= SyncDataS;
// либо из других полей объекта потока, например отражающих его тек.состояние
Form1.Label2.Caption:= Format("%d %d",);
end;
А вообще, примеру предшествовали следующие мои рассуждения на тему....
Во первых:
ВАЖНЕЙШЕЕ правило многопоточного программирования на Delphi:
В контексте не основного потока нельзя, обращаться к свойствам и методам форм, да и вообще всех компонентов которые "растут" из tWinControl.
Это означает (несколько упрощенно) что ни в методе Execute унаследованного от TThread, ни в других методах/процедурах/функциях вызываемых из Execute, нельзя напрямую обращаться ни к каким свойствам и методам визуальных компонентов.
Как делать правильно.
Тут единых рецептов нет. Точнее, вариантов так много и разных, что в зависимости от конкретного случая нужно выбирать. Поэтому к статье и отсылают. Прочитав и поняв ее, программист сможет понять и как лучше сделать в том или ином случае.
Если коротенько на пальцах:
Чаще всего, многопоточным приложение становится либо когда надо делать какую либо длительную работу, либо когда можно одновременно делать несколько дел, не сильно нагружающих процессор.
В первом случае, реализация работы внутри основного потока приводит к «торможению» пользовательского интерфейса – пока делается работа, не выполняется цикл обработки сообщений. Как следствие – программа не реагирует на действия пользователя, и не прорисовывается форма, например после ее перемещения пользователем.
Во втором случае, когда работа подразумевает активный обмен с внешним миром, то во время вынужденных «простоев». В ожидании получения/отправки данных, можно параллельно делать еще что-то, например, опять же другие посылать/принимать данные.
Существуют и другие случаи, но реже. Впрочем, это и не важно. Сейчас не об этом.
Теперь, как все это пишется. Естественно рассматривается некий наиболее частый случай, несколько обобщенный. Итак.
Работа, выносимая в отдельный поток, в общем случае имеет четыре сущности (уж и не знаю как назвать точнее):
1. Исходные данные
2. Собственно сама работа (она может зависеть от исходных данных)
3. Промежуточные данные (например, информация о текущем состоянии выполнения работы)
4. Выходные данные (результат)
Чаще всего для считывания и вывода большей части данных используются визуальные компоненты. Но, как было сказано выше – нельзя из потока напрямую обращаться к визуальным компонентам. Как же быть?
Разработчики Delphi предлагают использовать метод Synchronize класса TThread. Здесь я не буду описывать то, как его применять – для этого есть вышеупомянутая статья. Скажу лишь, что его применение, даже правильное, не всегда оправдано. Имеются две проблемы:
Во первых, тело метода вызванного через Synchronize всегда выполняется в контексте основного потока, и поэтому, пока оно выполняется, опять же не выполняется цикл обработки оконных сообщений. Следовательно, оно должно выполняться быстро, иначе, мы получим все те же проблемы что и при однопоточной реализации. В идеале, метод вызываемый через Synchronize вообще должен использоваться только для обращения к свойствам и методам визуальных объектов.
Во вторых, выполнение метода через Synchronize, это «дорогое» удовольствие, вызванное необходимостью двух переключений между потоками.
Причем, обе проблемы взаимосвязаны, и вызывают противоречие: с одной стороны, для решения первой, надо «размельчать» методы вызываемые через Synchronize, а с другой, их тогда чаще приходится вызывать, теряя драгоценный процессорный ресурс.
Поэтому, как всегда, надо подходить разумно, и для разных случаев, использовать разные способы взаимодействия потока с внешним миром:
Исходные данные
Все данные которые передаются в поток, и не изменяются во время его работы, нужно передавать еще до его запуска, т.е. при создании потока. Для их использования в теле потока, нужно сделать их локальную копию (обычно в полях потомка TThread).
Если есть исходные данные которые могут меняться во время работы потока, то доступ к таким данным нужно осуществлять либо через синхронизируемые методы (методы вызываемые через Synchronize), либо через поля объекта-потока (потомка TThread). Последнее требует определенной осторожности.
Промежуточные и выходные данные
Здесь, опять же есть несколько способов (в порядке моих предпочтений):
- Метод асинхронной отсылки сообщений главному окну приложению.
Используется обычно для отсылки основному окну приложения сообщений о состоянии протекания процесса, с передачей незначительного объема данных (например, процента выполнения)
- Метод синхронной отсылки сообщений главному окну приложению.
Используется обычно для тех же целей что и асинхронная отсылка, но позволяет передать больший объем данных, без создания отдельной копии.
- Синхронизируемые методы, по возможности, объединяя в один метод передачу как можно большего объема данных.
Можно использовать и для получения данных с формы.
- Через поля объекта-потока, обеспечением взаимоисключающего доступа.
Подробнее, можно почитать в статье.
Эх. Коротенько опять не получилось
Потоки и процессы - это связанные понятия в вычислительной технике. Оба представляют из себя последовательность инструкций, которые должны выполняться в определенном порядке. Инструкции в отдельных потоках или процессах, однако, могут выполняться параллельно.
Процессы существуют в операционной системе и соответствуют тому, что пользователи видят, как программы или приложения. Поток, с другой стороны, существует внутри процесса. По этой причине потоки иногда называются "облегченные процессы". Каждый процесс состоит из одного или более потоков. Существование нескольких процессов позволяет компьютеру "одновременно" выполнять несколько задач. Существование нескольких потоков позволяет процессу разделять работу для параллельного выполнения. На многопроцессорном компьютере процессы или потоки могут работать на разных процессорах. Это позволяет выполнять реально параллельную работу.
Абсолютно параллельная обработка не всегда возможна. Потоки иногда должны синхронизироваться. Один поток может ожидать результата другого потока, или одному потоку может понадобиться монопольный доступ к ресурсу, который используется другим потоком. Проблемы синхронизации являются распространенной причиной ошибок в многопоточных приложениях. Иногда поток может закончиться, ожидая ресурс, который никогда не будет доступен. Это кончается состоянием, которое называется взаимоблокировка.
Первое, что надо усвоить - процесс состоит хотя бы из одного потока . В ОС каждому процессу соответствует адресное пространство и одиночный управляющий поток. Фактически это и определяет процесс.
С одной стороны, процесс можно рассматривать как способ объединения родственных ресурсов в одну группу . У процесса есть адресное пространство, содержащее текст программы и данные, а также другие ресурсы. Ресурсами являются открытые файлы, дочерние процессы, необработанные аварийные сообщения, обобработчики сигналов, учетная информация и многое другое. Гораздо проще управлять ресурсами, объединив их в форме процесса.
С другой стороны, процесс можно рассматривать как поток исполняемых кокоманд или просто поток . У потока есть счетчик команд, отслеживающий порядок выполнения действий. У него есть регистры, в которых хранятся текущие переменные. У него есть стек, содержащий протокол выполнения процесса, где на каждую процедуру, вызванную, но еще не вернувшуюся, отведен отдельный фрейм. Хотя поток должен исполняться внутри процесса, следует различать концепции потока и процесса.Процессы используются для группирования ресурсов, а потоки являются объектами, поочередно исполняющимися на центральном процессоре.
Концепция потоков добавляет к модели процессавозможность одновременного выполнения в одной и той же среде процесса нескольких программ , в достаточной степени независимых. Несколько потоков, работающих параллельно в одном процессе, аналогичны нескольким процессам, идущим параллельно на одном компьютере. В первом случае потоки разделяют адресное пространство, открытые файлы и другие ресурсы. Во втором случае процессы совместно пользуются физической памятью, дисками, принтерами и другими ресурсами. Потоки обладают некоторыми свойствами процессов, поэтому их иногда называют упрощенными процессами. Терминмногопоточность также используется для описания использования нескольких потоков в одном процессе.
Любой поток состоит из двух компонентов:
объекта ядра
, через который операционная система управляет потоком. Там же хранится статистическая информация о потоке(дополнительные потоки создаются также ядром);
стека потока
, который содержит параметры всех функций и локальные переменные, необходимые потоку для выполнения кода.
Подводя черту, закрепим: главное отличие процессов от потоков , состоит в том, что процессы изолированы друг от друга, так используют разные адресные пространства, а потоки, могут использовать одно и то же пространство (внутри процесса) при этом, выполняя действия не мешаяя друг другу. В этом и заключается удобство многопоточного программинга : разбив приложение на несколько последовательных потоков, мы можем увеличить производительность, упростить пользовательский интерфейс и добиться масштабируемости (если Ваше приложение установят на многопроцессорную систему, выполняя потоки на разных процах, ваша прога будет работать с аховой скоростью=)).
1. Поток (thread) определяет последовательность исполнения кода в процессе.
2. Процесс ничего не исполняет, он просто служит контейнером потоков.
3. Потоки всегда создаются в контексте какого-либо процесса, и вся их жизнь проходит только в его границах.
4. Потоки могут исполнять один и тот же код и манипулировать одними и теми же данными, а также совместно использовать описатели объектов ядра, поскольку таблица описателей создается не в отдельных потоках, а в процессах.
5. Так как потоки расходуют существенно меньше ресурсов, чем процессы, старайтесь решать свои задачи за счет использования дополнительных потоков и избегайте создания новых процессов(но подходите к этому с умом).
Многозада́чность (англ. multitasking ) - свойство операционной системы или среды программирования обеспечивать возможность параллельной (или псевдопараллельной) обработки нескольких процессов. Истинная многозадачность операционной системы возможна только в распределённых вычислительных системах.
Файл:Screenshot of Debian (Release 7.1, "Wheezy") running the GNOME desktop environment, Firefox, Tor, and VLC Player.jpg
Рабочий стол современной операционной системы, отражающий активность нескольких процессов.
Существует 2 типа многозадачности :
· Процессная многозадачность (основанная на процессах - одновременно выполняющихся программах). Здесь программа - наименьший элемент кода, которым может управлять планировщик операционной системы. Более известна большинству пользователей (работа в текстовом редакторе и прослушивание музыки).
· Поточная многозадачность (основанная на потоках). Наименьший элемент управляемого кода - поток (одна программа может выполнять 2 и более задачи одновременно).
Многопоточность - специализированная форма многозадачности .
· 1 Свойства многозадачной среды
· 2 Трудности реализации многозадачной среды
· 3 История многозадачных операционных систем
· 4 Типы псевдопараллельной многозадачности
o 4.1 Невытесняющая многозадачность
o 4.2 Совместная или кооперативная многозадачность
o 4.3 Вытесняющая или приоритетная многозадачность (режим реального времени)
· 5 Проблемные ситуации в многозадачных системах
o 5.1 Голодание (starvation)
o 5.2 Гонка (race condition)
· 7 Примечания
Свойства многозадачной среды[править | править исходный текст]
Примитивные многозадачные среды обеспечивают чистое «разделение ресурсов», когда за каждой задачей закрепляется определённый участок памяти, и задача активизируется в строго определённые интервалы времени.
Более развитые многозадачные системы проводят распределение ресурсов динамически, когда задача стартует в памяти или покидает память в зависимости от её приоритета и от стратегии системы. Такая многозадачная среда обладает следующими особенностями:
· Каждая задача имеет свой приоритет, в соответствии с которым получает процессорное время и память
· Система организует очереди задач так, чтобы все задачи получили ресурсы, в зависимости от приоритетов и стратегии системы
· Система организует обработку прерываний, по которым задачи могут активироваться, деактивироваться и удаляться
· По окончании положенного кванта времени ядро временно переводит задачу из состояния выполнения в состояние готовности, отдавая ресурсы другим задачам. При нехватке памяти страницы невыполняющихся задач могут быть вытеснены на диск (своппинг), а потом через определённое системой время, восстанавливаться в памяти
· Система обеспечивает защиту адресного пространства задачи от несанкционированного вмешательства других задач
· Система обеспечивает защиту адресного пространства своего ядра от несанкционированного вмешательства задач
· Система распознаёт сбои и зависания отдельных задач и прекращает их
· Система решает конфликты доступа к ресурсам и устройствам, не допуская тупиковых ситуаций общего зависания от ожидания заблокированных ресурсов
· Система гарантирует каждой задаче, что рано или поздно она будет активирована
· Система обрабатывает запросы реального времени
· Система обеспечивает коммуникацию между процессами
Трудности реализации многозадачной среды[править | править исходный текст]
Основной трудностью реализации многозадачной среды является её надёжность, выраженная в защите памяти, обработке сбоев и прерываний, предохранении от зависаний и тупиковых ситуаций.
Кроме надёжности, многозадачная среда должна быть эффективной. Затраты ресурсов на её поддержание не должны: мешать процессам проходить, замедлять их работу, резко ограничивать память.
Многопото́чность - свойство платформы (например, операционной системы, виртуальной машины и т. д.) или приложения, состоящее в том, что процесс, порождённый в операционной системе, может состоять из нескольких потоков , выполняющихся «параллельно», то есть без предписанного порядка во времени. При выполнении некоторых задач такое разделение может достичь более эффективного использования ресурсов вычислительной машины.
Такие потоки называют также потоками выполнения (от англ. thread of execution ); иногда называют «нитями» (буквальный перевод англ. thread ) или неформально «тредами».
Сутью многопоточности является квазимногозадачность на уровне одного исполняемого процесса, то есть все потоки выполняются в адресном пространстве процесса. Кроме этого, все потоки процесса имеют не только общее адресное пространство, но и общиедескрипторы файлов. Выполняющийся процесс имеет как минимум один (главный) поток.
Многопоточность (как доктрину программирования) не следует путать ни с многозадачностью, ни с многопроцессорностью, несмотря на то, что операционные системы, реализующие многозадачность, как правило реализуют и многопоточность.
К достоинствам многопоточности в программировании можно отнести следующее:
· Упрощение программы в некоторых случаях за счет использования общего адресного пространства.
· Меньшие относительно процесса временны́е затраты на создание потока.
· Повышение производительности процесса за счет распараллеливания процессорных вычислений и операций ввода-вывода.
· 1 Типы реализации потоков
· 2 Взаимодействие потоков
· 3 Критика терминологии
· 6 Примечания
Типы реализации потоков[править | править исходный текст]
· Поток в пространстве пользователя. Каждый процесс имеет таблицу потоков, аналогичную таблице процессов ядра.
Достоинства и недостатки этого типа следующие: Недостатки
1. Отсутствие прерывания по таймеру внутри одного процесса
2. При использовании блокирующего системного запроса для процесса все его потоки блокируются.
3. Сложность реализации
· Поток в пространстве ядра. Наряду с таблицей процессов в пространстве ядра имеется таблица потоков.
· «Волокна» (англ. fibers ). Несколько потоков режима пользователя, исполняющихся в одном потоке режима ядра. Поток пространства ядра потребляет заметные ресурсы, в первую очередь физическую память и диапазон адресов режима ядра для стека режима ядра. Поэтому было введено понятие «волокна» - облегчённого потока, выполняемого исключительно в режиме пользователя. У каждого потока может быть несколько «волокон».
Взаимодействие потоков[править | править исходный текст]
В многопоточной среде часто возникают проблемы, связанные с использованием параллельно исполняемыми потоками одних и тех же данных или устройств. Для решения подобных проблем используются такие методы взаимодействия потоков, как взаимоисключения (мьютексы), семафоры, критические секции и события
· Взаимоисключения (mutex, мьютекс) - это объект синхронизации, который устанавливается в особое сигнальное состояние, когда не занят каким-либо потоком. Только один поток владеет этим объектом в любой момент времени, отсюда и название таких объектов (от английского mut ually ex clusive access - взаимно исключающий доступ) - одновременный доступ к общему ресурсу исключается. После всех необходимых действий мьютекс освобождается, предоставляя другим потокам доступ к общему ресурсу. Объект может поддерживать рекурсивный захват второй раз тем же потоком, увеличивая счетчик, не блокируя поток, и требуя потом многократного освобождения. Такова, например, критическая секция в Win32. Тем не менее есть и такие реализации, которые не поддерживают такое и приводят к взаимной блокировке потока при попытке рекурсивного захвата. Это FAST_MUTEX в ядре Windows.
· Семафоры представляют собой доступные ресурсы, которые могут быть приобретены несколькими потоками в одно и то же время, пока пул ресурсов не опустеет. Тогда дополнительные потоки должны ждать, пока требуемое количество ресурсов не будет снова доступно. Семафоры очень эффективны, поскольку они позволяют одновременный доступ к ресурсам. Семафор есть логическое расширение мьютекса - семафор со счетчиком 1 эквивалентен мьютексу, но счетчик может быть и более 1.
· События. Объект, хранящий в себе 1 бит информации «просигнализирован или нет», над которым определены операции «просигнализировать», «сбросить в непросигнализированное состояние» и «ожидать». Ожидание на просигнализированном событии есть отсутствие операции с немедленным продолжением исполнения потока. Ожидание на непросигнализированном событии приводит к приостановке исполнения потока до тех пор, пока другой поток (или же вторая фаза обработчика прерывания в ядре ОС) не просигнализирует событие. Возможно ожидание нескольких событий в режимах «любого» или «всех». Возможно также создания события, автоматически сбрасываемого в непросигнализированное состояние после пробуждения первого же - и единственного - ожидающего потока (такой объект используется как основа для реализации объекта «критическая секция»). Активно используются в MS Windows, как в режиме пользователя, так и в режиме ядра. Аналогичный объект имеется и в ядре Linux под названием kwait_queue.
· Критические секции обеспечивают синхронизацию подобно мьютексам за исключением того, что объекты, представляющие критические секции, доступны в пределах одного процесса. События, мьютексы и семафоры также можно использовать в однопроцессном приложении, однако реализации критических секций в некоторых ОС (например, Windows NT) обеспечивают более быстрый и более эффективный механизм взаимно-исключающей синхронизации - операции «получить» и «освободить» на критической секции оптимизированы для случая единственного потока (отсутствия конкуренции) с целью избежать любых ведущих в ядро ОС системных вызовов. Подобно мьютексам объект, представляющий критическую секцию, может использоваться только одним потоком в данный момент времени, что делает их крайне полезными при разграничении доступа к общим ресурсам.
· Условные переменные (condvars). Сходны с событиями, но не являются объектами, занимающими память - используется только адрес переменной, понятие «содержимое переменной» не существует, в качестве условной переменной может использоваться адрес произвольного объекта. В отличие от событий, установка условной переменной в просигнализированное состояние не влечет за собой никаких последствий в случае, если на данный момент нет потоков, ожидающих на переменной. Установка события в аналогичном случае влечет за собой запоминание состояния «просигнализировано» внутри самого события, после чего следующие потоки, желающие ожидать события, продолжают исполнение немедленно без остановки. Для полноценного использования такого объекта необходима также операция «освободить mutex и ожидать условную переменную атомарно». Активно используются в UNIX-подобных ОС. Дискуссии о преимуществах и недостатках событий и условных переменных являются заметной частью дискуссий о преимуществах и недостатках Windows и UNIX.
· Порт завершения ввода-вывода (IO completion port, IOCP). Реализованный в ядре ОС и доступный через системные вызовы объект «очередь» с операциями «поместить структуру в хвост очереди» и «взять следующую структуру с головы очереди» - последний вызов приостанавливает исполнение потока в случае, если очередь пуста, и до тех пор, пока другой поток не осуществит вызов «поместить». Самой важной особенностью IOCP является то, что структуры в него могут помещаться не только явным системным вызовом из режима пользователя, но и неявно внутри ядра ОС как результат завершения асинхронной операции ввода-вывода на одном из дескрипторов файлов. Для достижения такого эффекта необходимо использовать системный вызов «связать дескриптор файла с IOCP». В этом случае помещенная в очередь структура содержит в себе код ошибки операции ввода-вывода, а также, для случая успеха этой операции - число реально введенных или выведенных байт. Реализация порта завершения также ограничивает число потоков, исполняющихся на одном процессоре/ядре после получения структуры из очереди. Объект специфичен для MS Windows, и позволяет обработку входящих запросов соединения и порций данных в серверном программном обеспечении в архитектуре, где число потоков может быть меньше числа клиентов (нет требования создавать отдельный поток с расходами ресурсов на него для каждого нового клиента).
· ERESOURCE. Мьютекс, поддерживающий рекурсивный захват, с семантикой разделяемого или эксклюзивного захвата. Семантика: объект может быть либо свободен, либо захвачен произвольным числом потоков разделяемым образом, либо захвачен всего одним потоком эксклюзивным образом. Любые попытки осуществить захваты, нарушающее это правило, приводят к блокировке потока до тех пор, пока объект не освободится так, чтобы сделать захват разрешенным. Также есть операции вида TryToAcquire - никогда не блокирует поток, либо захватывает, либо (если нужна блокировка) возвращает FALSE, ничего не делая. Используется в ядре Windows, особенно в файловых системах - так, например, любому кем-то открытому дисковому файлу соответствует структура FCB, в которой есть 2 таких объекта для синхронизации доступа к размеру файла. Один из них - paging IO resource - захватывается эксклюзивно только в пути обрезания файла, и гарантирует, что в момент обрезания на файле нет активного ввода-вывода от кэша и от отображения в память.
· Rundown protection. Полудокументированный (вызовы присутствуют в файлах-заголовках, но отсутствуют в документации) объект в ядре Windows. Счетчик с операциями «увеличить», «уменьшить» и «ждать». Ожидание блокирует поток до тех пор, пока операции уменьшения не уменьшат счетчик до нуля. Кроме того, операция увеличения может отказать, и наличие активного в данный момент времени ожидания заставляет отказывать все операции увеличения.
