Почему является явное управление потоками плохой вещью?

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

Я думаю, что первое утверждение лучше всего объяснить как таковое: с теперь доступно множество расширенных API , вручную писать собственный код потока почти никогда не нужно. Новые API проще в использовании, а труднее испортить !. Принимая во внимание, что со старым стилем потоковой передачи вы должны быть достаточно хороши, чтобы не испортить. API старого стиля ( Thread и др.) Все еще доступны, но новые API ( Task Parallel Library , Parallel LINQ и Реактивные расширения ) - это путь в будущее.

Второе утверждение больше с точки зрения дизайна, ИМО. В дизайне с четким разделением задач фоновая задача не должна напрямую попадать в пользовательский интерфейс, чтобы сообщать об обновлениях. Там должно быть какое-то разделение, используя такой шаблон, как MVVM или MVC.

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

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

 public static class UIThreadSafe {

     public static void Perform(Control c, MethodInvoker inv) {
            if(c == null)
                return;
            if(c.InvokeRequired) {
                c.Invoke(inv, null);
            }
            else {
                inv();
            }
      }
  }

Вы можете использовать это в любом потоке, которому необходимо изменить элемент пользовательского интерфейса, например:

UIThreadSafe.Perform(myForm, delegate() {
     myForm.Title = "I Love Threads!";
});

Я бы начал с сомнения в этом восприятии:

Я читал о нитках и у меня сложилось впечатление, что они были самыми вкусными вещами после желе из киви.

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

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

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

И последнее, создание потока на самом деле очень дорого. Использование пула потоков снижает эту стоимость, потому что здесь среда выполнения создает ряд потоков, которые впоследствии используются повторно. Когда люди говорят, что явное управление потоками - это плохо, это все, что они могут иметь в виду.

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

Кроме того, большая часть кода фреймворка намеренно написана с расчетом на разделение пользовательского интерфейса и обработки; программы будут работать лучше, когда вы разделите их, и будут сталкиваться с ошибками и проблемами, когда вы этого не сделаете. Я не помню каких-либо конкретных проблем, с которыми я столкнулся в результате этого, хотя у меня есть смутные воспоминания о том, как в прошлом пытались установить определенные свойства материала, за который пользовательский интерфейс был ответственен за пределами пользовательского интерфейса, и что код отказывался работать; Я не помню, не компилировался ли он или вызывал исключение.

При обновлении пользовательского интерфейса из потока, отличного от пользовательского интерфейса, важно отметить несколько моментов:

1. Если вы часто используете «Invoke», производительность ваш поток, не связанный с пользовательским интерфейсом, может серьезно пострадать, если другие факторы заставят поток пользовательского интерфейса работать медленно. Я предпочитаю избегать использования «Invoke», если только потоку, не относящемуся к пользовательскому интерфейсу, нужно дождаться выполнения действия потока пользовательского интерфейса, прежде чем оно продолжится.
2. Если вы опрометчиво используете «BeginInvoke» для таких вещей, как обновления элементов управления, чрезмерное количество делегатов вызова может оказаться в очереди, некоторые из которых вполне могут оказаться довольно бесполезными к тому времени, когда они действительно произойдут.

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

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

Явное управление потоками не по своей сути плохая вещь, но она чревата опасностями, и ее нельзя делать без крайней необходимости.

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

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

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

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

Многие продвинутые GUI-приложения обычно состоят из двух потоков, один для пользовательского интерфейса, один (или иногда больше) для обработки данных (копирование файлов, выполнение тяжелых вычислений, загрузка данных из базы данных и т.д.).

Потоки обработки не должны обновлять пользовательский интерфейс напрямую, пользовательский интерфейс должен быть для них "черным ящиком" (см. Википедию о инкапсуляции).
Они просто говорят "Я закончил обработку" или "Я выполнил задание 7 из 9" и вызывают событие или другой метод обратного вызова. Пользовательский интерфейс подписывается на событие, проверяет, что изменилось, и обновляет пользовательский интерфейс соответствующим образом.

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

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

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

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

void Thread()
{
   if (list.Count > 0)
   {
      /// Do stuff
      list.RemoveAt(0);
   }
}

Помните, что потоки, теоретически, могут переключиться в любой строке вашего кода, который не синхронизирован. Так, если список содержит только один элемент, один поток может пройти условие list.Count, непосредственно перед list.Remove потоки переключаются и другой поток проходит list.Count (список по-прежнему содержит один элемент). Теперь первый поток продолжает list.Remove, а после него второй поток продолжает list.Remove, но последний элемент уже удален первым потоком, поэтому второй поток терпит крах. Поэтому его нужно синхронизировать с помощью оператора lock, чтобы не возникло ситуации, когда два потока находятся внутри оператора if.

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

В предыдущих версиях .NET, если вы хотели обновить UI в другом потоке, вы должны были синхронизироваться с помощью методов Invoke, но поскольку это было достаточно сложно реализовать, в новых версиях . NET поставляются с классом BackgroundWorker, который упрощает задачу, оборачивая все вещи и позволяя вам делать асинхронные вещи в событии DoWork и обновлять UI в событии ProgressChanged.