Проблема конкуренции и роль синхронизации потоков

Проблема конкуренции и роль синхронизации потоков

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

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

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

Атомарные операции, с другой стороны, всегда безопасны в многопоточном окружении. К сожалению, только для очень небольшого числа операций из библиотек базовых классов .NET можно гарантировать, что эти операции будут атомарными. Не является атомарной даже операция присваивание значения члену-переменной! Если в документации .NET Framework 2.0 SDK в отношении какой-либо операции специально не оговорено, что данная операция является атомарной, вы должны предполагать, что эта операция является открытой влиянию потоков и принимать специальные меры предосторожности.

Теперь вам должно быть ясно, что домены многопоточного приложения тоже открыты влиянию потоков, поскольку потоки могут пытаться использовать доступные функциональные возможности одновременно. Чтобы защитить ресурсы приложения от возможных искажении, разработчикам .NET приходится использовать так называемые примитивы потоков (такие, как блокировки, мониторы и атрибут [Synchronization]), чтобы контролировать доступ выполняемых потоков.

Нельзя утверждать, что платформа .NET исключила все трудности, возникающие при построении устойчивых многопоточных приложений, но теперь этот процесс значительно упрощён. Используя типы, определенные в пространстве имен System.Threading, вы получаете возможность создавать дополнительные потоки с минимальными усилиями и минимальными проблемами. Точно так же, когда приходит время блокировать открытые элементы данных, вы можете использовать дополнительные типы, которые обеспечивают те же функциональные возможности, что и примитивы потоков Win32 API (но при этом используется намного более аккуратная объектная модель).

Однако использование пространства имея System.Threading – это не единственный путь построения многопоточных программ .NET. В ходе нашего обсуждения делегатов (см. главу 8) мы уже упоминали о том, что все делегаты NET обладают способностью асинхронного вызова членов. Это – главное преимущество платформы .NET, поскольку одной из основных причин, в силу которых разработчик создает потоки, является необходимость такого вызова методов, при котором не возникает блокировок (т.е. именно асинхронного вызова). Для достижения такого результата можно использовать и пространство имен System.Threading, но с помощью делегатов это делается намного проще.

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг

Проблема тогда, когда это проблема

Из книги Getting Real (на русском) [вычитывается] автора 37signals

Проблема тогда, когда это проблема Не тратьте бесцельно время на проблемы, которых у вас еще нетВам действительно нужно волноваться о вычислениях для 100 000 потребителей сегодня, если это будет у вас через два года?Действительно вам нужно нанять восемь программистов, если


5.16.2 Поводы для конкуренции

Из книги Архитектура операционной системы UNIX автора Бах Морис Дж

5.16.2 Поводы для конкуренции Поводов для конкуренции при выполнении системной функции unlink очень много, особенно при удалении имен каталогов. Команда rmdir удаляет каталог, убедившись предварительно в том, что в каталоге отсутствуют файлы (она считывает каталог и проверяет


Результаты синхронизации потоков

Из книги UNIX: взаимодействие процессов автора Стивенс Уильям Ричард

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


Необходимость в синхронизации потоков

Из книги Системное программирование в среде Windows автора Харт Джонсон М

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


Объекты синхронизации потоков

Из книги TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security) автора Фейт Сидни М

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


ГЛАВА 10 Усовершенствованные методы синхронизации потоков

Из книги Удвоение продаж в интернет-магазине автора Парабеллум Андрей Алексеевич

ГЛАВА 10 Усовершенствованные методы синхронизации потоков В предыдущей главе были описаны проблемы производительности, возникающие в Windows, и способы их преодоления в реалистичных ситуациях. В главе 8 обсуждался ряд простых задач, требующих привлечения объектов


Стеки потоков и допустимые количества потоков

Из книги QNX/UNIX [Анатомия параллелизма] автора Цилюрик Олег Иванович

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


13.9.1 Сигнал синхронизации

Из книги Введение в QNX/Neutrino 2. Руководство по программированию приложений реального времени в QNX Realtime Platform автора Кёртен Роб

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


Зачем выходить из ценовой конкуренции

Из книги Установка, настройка и восстановление Windows 7 на 100% автора Ватаманюк Александр Иванович

Зачем выходить из ценовой конкуренции Для интернет-магазина ценовая конкуренция – прямой путь к банкротству (насколько быстрый – другой вопрос). Ее могут позволить себе только крупные фирмы за счет своих гигантских оборотов.Нужно понимать, что в любой нише Интернета


Бонус № 3. Принцип УТП, гарантированно повышающий эффективность рекламы независимо от конкуренции

Из книги Разработка ядра Linux автора Лав Роберт

Бонус № 3. Принцип УТП, гарантированно повышающий эффективность рекламы независимо от конкуренции В современных условиях интернет-бизнеса трудно предложить потребителю то, чего еще не предлагали ваши конкуренты. С каждым днем все сложнее вырабатывать свою, отличную от


4. Примитивы синхронизации

Из книги автора

4. Примитивы синхронизации ОС QNX Neutrino предоставляет широкий набор элементов синхронизации выполнения потоков, как в рамках одного процесса, так и разных. Это практически полный спектр примитивов, описываемых как базовым стандартом POSIX, так и всеми его расширениями


Дополнительно о синхронизации

Из книги автора

Дополнительно о синхронизации Мы уже обсудили:• мутексы;• семафоры;• барьеры.Давайте теперь завершим нашу дискуссию о синхронизации, обсудив следующее:• блокировки чтения/записи (reader/writer locks);• ждущие блокировки (sleepons);• условные переменные (condition


Центр синхронизации

Из книги автора

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


Критические участки и состояние конкуренции за ресурсы

Из книги автора

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


Резюмирование по синхронизации

Из книги автора

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


Состояния конкуренции, связанные с таймерами

Из книги автора

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