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

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

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

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

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

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

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

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

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