Дочерние окна со своим потоком внутри главного

[constant_ural]

Возможно ли реализовать приложение следующим образом. Есть главное окно. Внутри него имеются другие окна (или контролы),
жестко прикрепленые ("докируемые") друг с другом. Важно, что эти дочерние окна запущенны каждый в своем потоке,
и соответственно со своим диспетчером, т.е обработка данных в окнах происходит параллельно.
Идеально, чтобы это все было полностью на WPF. Ну или хотябы сами окна (контролы) на WPF.
Ну если и так невозможно, то скажите как по другому.
Я знаю по-отдельности: 1)Как запустить WPF окно в собственном потоке. 2) Как поместить в грид WPF содержимое другого
окна. НО. Вместе это не работает

Просьба написать хотя бы возможно или нет и, если да, то как.

[Luuzuk]

Не надо разных диспетчеров, это лишнее.
Просто обработку данных ведите в разных потоках, и все.

Почти уверен, что это ваш случай: http://www.gunsmoker.ru/2008/10/x-y-z.html
Задачу-то изначальную расскажите

[constant_ural]

Сообщение от Luuzuk

Задачу-то изначальную расскажите

Данные обрабатываются в нескольких отдельных потоках.
Результат обработки этим потокам нужно выводить в окно.
При этом данные могут изменяться достаточно часто, но нужно, чтобы была сохранена очередность, в которой данные на форме изменились. При этом логически есть разные объекты вывода. Сейчас это в виде контролов в одном окне.
Invoke работает ну очень медленно. BeginInvoke несколько быстрее, но все равно медленно, плюс там нарушается очередность выполнения, когда несколько "писателей" (потоков) как в моем случае. И в обоих случаях обновляется содержимое окна тормознуто.
Дополнительные (вспомогательные) окна я создаю в отдельных потоках, со своими диспетчерами и это работает хорошо.

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

[Luuzuk]

А через Binding не проще? Вывод через Invoke в контролы wpf изначально не очень хорошая затея
Если поделитесь информацией что за контролы и какого рода данные вы в них выводите, то могу попробовать более конкретное предложение высказать )

[constant_ural]

А через Binding не проще? Вывод через Invoke в контролы wpf изначально не очень хорошая затея

Вы имеете в виду сделать Binding. И делать RaisePropertyChanged из потока где делается обработка данных ? Здесь проблема, в том, что задержки в потоке где происходит обработка данных не желательна, а при вызове RaisePropertyCHanged она существенна. Здесь возможен вариант промежуточного потока worker-а с очередью в которую вычислительным потоком будут добавляться Action-ы на обновление. А этот worker уже эти Action-ы выполнять. Собственно так все у меня и реализовано. Только пришлось делать BerginInvoke потому что выдается исключение, что объект принадлежит другому потоку.

[Luuzuk]

1) Вычислительный поток складывает результаты своей работы в, допустим, некоторый List<TResult>. Никаких оповещений не вызывает
2) Работающий DispatcherTimer раз в N времени вызывает PropertyChanged
2.1) Если использовать Binding религиозные убеждения не позволяют, то таймер может эти результаты на форму выводить и "напрямую", т.е. через View.textBox1.Text="someshit"

3) Если хранить результаты вычислений в листе постоянно вы не хотите, то прямой путь к неблокирующим потокобезопасным коллекциям типа ConcurrentQueue<TResult>. Тогда в таймере раз в N времени будете извлекать из очереди результаты работы вычислительного потока, скажем, пачками по 10-20 результатов, и эти результаты отображать на UI.

Таким образом вы обеспечите и упорядоченность обработки результатов (потокобезопасная очередь это обеспечит), и поток вычислений не будете загружать ненужной ему работой по отображению результатов на UI

Как вам такая затея?

[constant_ural]

1) Вычислительный поток складывает результаты своей работы в, допустим, некоторый List<TResult>. Никаких оповещений не вызывает
2) Работающий DispatcherTimer раз в N времени вызывает PropertyChanged
2.1) Если использовать Binding религиозные убеждения не позволяют, то таймер может эти результаты на форму выводить и "напрямую", т.е. через View.textBox1.Text="someshit"

3) Если хранить результаты вычислений в листе постоянно вы не хотите, то прямой путь к неблокирующим потокобезопасным коллекциям типа ConcurrentQueue<TResult>. Тогда в таймере раз в N времени будете извлекать из очереди результаты работы вычислительного потока, скажем, пачками по 10-20 результатов, и эти результаты отображать на UI.

Таким образом вы обеспечите и упорядоченность обработки результатов (потокобезопасная очередь это обеспечит), и поток вычислений не будете загружать ненужной ему работой по отображению результатов на UI

Как вам такая затея?

Luuzuk, примерно в таком ключе я и думал. Но. Что, если будет ОЧЕНЬ много контролов с данными для обновления, и они будут ОЧЕНЬ часто обновляться. А поток обновления-то один ! Т.е один потребитель, а производителей несколько. Не будет ли это в какой-то момент виснуть, тормозить и глючить, этот потребитель (UI), большая часть операций на одном процессорном ядре будет работать, а остальные семь простаивать будут ?

[Luuzuk]

А их не надо ОЧЕНЬ часто обновлять, в том-то и вся фишка. Пользователю не надо 100500 обновлений UI в секунду, вы же с такой скоростью читать (глазами) данные с экрана не сможете )
Обновление раз в 0.5-1 секунды вас разве чем-то не устроит? При условии, что в контролы попадут все результаты, которые в течение этой секунды были получены от вычислительного потока. А частоту обновления можно очень легко регулировать интервалом таймера