Почему невозможно обновить ObservableCollection из другого потока?

Во-первых ... Я чувствую твою боль. Ограничение потока пользовательского интерфейса может быть проблемой ...

Почему вы не можете обновить элемент пользовательского интерфейса из нить, отличная от той, которая была создано?

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

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

Почему нельзя было разрешить сбор обновлений из любого потока?

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

Я знаю, что есть обходные пути, поэтому мой вопрос не в том, как избежать этого тип CollectionView не поддержать изменения в SourceCollection из потока отличается от потока Диспетчера " исключение.

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

... блокировать обновление пользовательского интерфейса, когда ObservableCollection изменен с другие потоки .... он всегда будет работать, по крайней мере, если используются замки правильно ....

Если замки используются правильно ... Именно! Опять же, Microsoft могла установить эти блокировки, но они этого не сделали, и по очень веским причинам. Вы можете установить блокировки. Или вы можете использовать другую тактику, которая даст вам поточно-безопасный доступ ... множество вариантов.

Библиотека параллельных задач в .net4.0 предоставляет некоторые новые инструменты для решения этих проблем. Возможность установить контекст для задачи или потока особенно полезна ...

  // get the Ui thread context
  _uiScheduler = TaskScheduler.FromCurrentSynchronizationContext();

  Action DoInBackground = new Action(() =>
  {
    /*...In the background...
      ...process some data for an ObservableCollection...*/
  });

  Action DoOnUiThread = new Action(() =>
  { 
    /*...On the UI thread...
      ...read/write data to an ObservableCollection...*/
  });

  // start the background task
  var t1 = Task.Factory.StartNew(() => DoInBackground());
  // when t1 is done run t1..on the Ui thread.
  var t2 = t1.ContinueWith(t => DoOnUiThread(), _uiScheduler);

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

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

Я иду покурить.