Ниже приведен модифицированный код, где вместо литерального объекта делегата Action<T> применяется лямбда-операция С#. Как видите, в коде закомментированы строки, которые отображают идентификатор потока, обрабатывающего текущий файл изображения. Причина объясняется в следующем разделе.
<b>// Обработать данные изображений в параллельном режиме!</b>
Parallel.ForEach(files, currentFile =>
{
string filename = Path.GetFileName(currentFile);
<b> // Этот оператор теперь приводит к проблеме! См. следующий раздел.</b>
<b> // this.Title = $" Processing {filename} on thread</b>
<b> // {Thread.CurrentThread.ManagedThreadld}"</b>
<b> // Thread.CurrentThread.ManagedThreadld);</b>
using (Bitmap bitmap = new Bitmap( currentFile))
using (Bitmap bitmap = new Bitmap(currentFile))
{
bitmap.RotateFlip(RotateFlipType.Rotate180FlipNone);
bitmap.Save(Path.Combine(outputDirectory, filename));
}
}
);
Доступ к элементам пользовательского интерфейса во вторичных потоках
Вы наверняка заметили, что в показанном выше коде закомментированы строки, которые обновляют заголовок главного окна значением идентификатора текущего выполняющегося потока. Как упоминалось ранее, элементы управления графического пользовательского интерфейса привязаны к потоку, где они были созданы. Если вторичные потоки пытаются получить доступ к элементу управления, который они напрямую не создавали, то при отладке программного обеспечения возникают ошибки времени выполнения. С другой стороны, если запустить приложение (нажатием <Ctrl+F5>), тогда первоначальный код может и не вызвать каких-либо проблем.
На заметку! Не лишним будет повторить: при отладке многопоточного приложения вы иногда будете получать ошибки, когда вторичный поток обращается к элементу управления, созданному в первичном потоке. Однако часто после запуска приложение может выглядеть функционирующим корректно (или же довольно скоро может возникнуть ошибка). Если не предпринять меры предосторожности (описанные далее), то приложение в подобных обстоятельствах может потенциально сгенерировать ошибку во время выполнения.
Один из подходов, который можно использовать для предоставления вторичным потокам доступа к элементам управления в безопасной к потокам манере, предусматривает применение другого приема — анонимного делегата. Родительский класс Control в WPF определяет объект Dispatcher, который управляет рабочими элементами для потока. Указанный объект имеет метод по имени Invoke(), принимающий на входе System.Delegate. Этот метод можно вызывать внутри кода, выполняющегося во вторичных потоках, чтобы обеспечить возможность безопасного в отношении потоков обновления пользовательского интерфейса для заданного элемента управления. В то время как весь требуемый код делегата можно было бы написать напрямую, большинство разработчиков используют в качестве простой альтернативы синтаксис выражений. Вот как выглядит модифицированный код:
(window.adrunTag = window.adrunTag || []).push({v: 1, el: 'adrun-4-390', c: 4, b: 390})
<b>// Этот код больше не работает!</b>
<b>// this.Title = $"Processing {filename} on thread {Thread.</b>
<b>// CurrentThread.ManagedThreadld}";</b>
<b>// Вызвать Invoke() на объекте Dispatcher, чтобы позволить вторичным потокам</b>
<b>// получать доступ к элементам управления в безопасной к потокам манере.</b>
Dispatcher?.Invoke(() =>
{
this.Title = $"Processing {filename}";
});
using (Bitmap bitmap = new Bitmap(currentFile))
{
bitmap.RotateFlip(RotateFlipType.Rotate180FlipNone);
bitmap.Save(Path.Combine(outputDirectory, filename));
}
Теперь после запуска программы библиотека TPL распределит рабочую нагрузку по множеству потоков из пула, используя столько процессоров, сколько возможно. Тем не менее, поскольку заголовок Title всегда обновляется из главного потока, код обновления Title больше не отображает текущий поток, и при вводе в текстовой области вы ничего не увидите до тех пор, пока не обработаются все файлы изображений! Причина в том, что первичный поток пользовательского интерфейса по-прежнему блокируется, ожидая завершения работы всех остальных потоков.
Класс Task
Класс Task позволяет легко вызывать метод во вторичном потоке и может применяться как простая альтернатива асинхронным делегатам. Измените обработчик события Click элемента управления Button следующим образом:
private void cmdProcess_Click(object sender, EventArgs e)
{
// Запустить новую "задачу" для обработки файлов.
Task.Factory.StartNew(() => ProcessFiles());
// Можно записать и так:
// Task.Factory.StartNew(ProcessFiles);
}
Свойство Factory класса Task возвращает объект TaskFactory. Методу StartNew() при вызове передается делегат Action<T> (что здесь скрыто с помощью подходящего лямбда-выражения), указывающий на метод, который подлежит вызову в асинхронной манере. После такой небольшой модификации вы обнаружите, что заголовок окна отображает информацию о потоке из пула, обрабатывающем конкретный файл, а текстовое поле может принимать ввод, поскольку пользовательский интерфейс больше не блокируется.
