Любопытные проекты.

anothar: Натолкнулся на кодплексе на любопытный проект: WPF RealTime. Насколько он полезен непонятно. Но скорее всего оттуда можно вытащить многопоточную модель, организованную на основе TPL.

Посмотрел решение - зов из прошлого. Писать код на уровне примитивов без ООП и выделения памяти - это на любителя.

Mikhail Sukhov:

anothar: Натолкнулся на кодплексе на любопытный проект: WPF RealTime. Насколько он полезен непонятно. Но скорее всего оттуда можно вытащить многопоточную модель, организованную на основе TPL.

Посмотрел решение - зов из прошлого. Писать код на уровне примитивов без ООП и выделения памяти - это на любителя.

то есть как это без ООП? это что все в одну строчку как функциональное программирование :) и как это без выделения памяти? что совсем без памяти программа работает? :)

нет уж позвольте обьяснить свою точку зрения

oshelest: то есть как это без ООП? это что все в одну строчку как функциональное программирование :) и как это без выделения памяти? что совсем без памяти программа работает? :)

нет уж позвольте обьяснить свою точку зрения

За кучей папок я нашел самую сердцевину http://wpfrealtime.codeplex.com/SourceControl/changeset/view/11996#153533 Идея, как я понял, заключается в том, чтобы не запускать GC. Нет запущенного GC, значит код работает детерминировано. В .NET единственный способ не запускать GC - или его принудительно запускать после определенных действий (что неправильно, и только снизит производительность), или не пользоваться выделением памяти, и работать только со стековыми объектами (скорее всего, еще и с неким пулов объектов, так как чисто на стеке сделать программу такого уровня как на картинке невозможно). Последнее, как я понял и используется в приведенной ссылке. Тоесть, мы оперируем не множеством объектов, к которому может применять LINQ преобразования, а с обычной таблицей, и применяем уже табличную трансформацию.

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

Хмм любопытно в стеке хранятся по идее только структуры, которые и были созданы для того чтобы их можно было в большом объеме создавать. Правда тогда прощай ооп-нет поддержки наследования. LINQ поддерживает сруктуры. Какую обычную таблицу вы имеете ввиду? DataTable?-она то хранится как раз таки в куче. А вот приведенный код скорее просто генератор случайных данных-просто пример коннектора. Стек тоже очищается при выходе за пределы. А так у C# впринципе неплохая скорость-тут впринципе интерес только в том как грамотно распределять потоки. Судя по статье- основная фича там в том что есть небольшое запаздывание в уведомлении гуи об изменениях, чтобы множество изменений выполнилось как одно-идея вполне разумная если скажем у вас открыта куча стаканов и графиков-то есть при множественном обновлении.

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

Да, это интересно. Можете кинуть прямой ссылкой именно на сам исходник, как это реализуется? Я лично это делаю через Unity + свой вспомогательный класс GuiDispatcher, который в себе содержит авто запускаемый DispatcherTimer.

До конца не дочитал статью. Я начал читать и честно ее дочитал до начала сравнения платформ. Введение было вообщем и ни о чем, или я так до сих пор и не понял о чем проект. Сравнение тоже какое-то скудное, на Stack-е описание лучше. Потом какие то картинки со слабо разборчивым шрифтом, и далее код-код-код... Вообщем из статьи ничего не понял. Из титульника на КП тоже слабо понятно, что это такое: библиотека, некая концепция или готовое приложение-демонстрация.

Проект в целом не плохой, раз тема RT поднимается, тем более в трейдинг сфере[thumbup]. Но описание нужно нормальное.

Mikhail Sukhov:

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

Да, это интересно. Можете кинуть прямой ссылкой именно на сам исходник, как это реализуется? Я лично это делаю через Unity + свой вспомогательный класс GuiDispatcher, который в себе содержит авто запускаемый DispatcherTimer.

До конца не дочитал статью. Я начал читать и честно ее дочитал до начала сравнения платформ. Введение было вообщем и ни о чем, или я так до сих пор и не понял о чем проект. Сравнение тоже какое-то скудное, на Stack-е описание лучше. Потом какие то картинки со слабо разборчивым шрифтом, и далее код-код-код... Вообщем из статьи ничего не понял. Из титульника на КП тоже слабо понятно, что это такое: библиотека, некая концепция или готовое приложение-демонстрация.

Проект в целом не плохой, раз тема RT поднимается, тем более в трейдинг сфере[thumbup]. Но описание нужно нормальное.

"основных" идей несколько:

1. "небольшое запаздывание" или буферизация данных http://wpfrealtime.codeplex.com/SourceControl/changeset/view/11996#153595

2. неблокирующая синхронизация http://wpfrealtime.codeplex.com/SourceControl/changeset/view/11996#153534

3.Медиатор http://wpfrealtime.codeplex.com/SourceControl/changeset/view/11996#153548

4. А так же реализован планировщик задач реального времени http://wpfrealtime.codeplex.com/SourceControl/changeset/view/11996#153583

Чего там непонятного? вроде все так доступно описал и шуточки добавил про жизнь свою что б товарищи не ленились до конца дочитать. А Михаил говорит даже титульник не понял :( Там же русским языком написано "trading application framework".

То есть если хочешь как GUI framework использовать - пиши свои маркет адаптеры + модули и торгуй и богатей А хочешь вытащить многопоточную модель как советует anothar тогда Mediator.cs (п.3) и PriorityTaskScheduler.cs (п.4) твои друзья. Их можно к любому GUI прикрутить

1. Основан на Reactive Extensions-по сути опрашивает события с заданным интервалом.
2. Обычная реализация INOtifyPropertyChanged, но с пакетным уведомлением(обычная ObservableCollection уведомляет о каждом чихе). 3)Рапределение задач по шедулерам-периодические задачи получают главный приоритет(ака реалтаймовость)- а именно они и обновляют гуи. 4)Планировщик задач реального времени по сути просто запускает число задач соответствующее числу ядер(строчка _backgroundTaskFactory.StartNew(() => { while (true) {... ), что мне не очень нравится. Через заданные промежутки времени кладет в очередь сообщения а задачи их считывают-по идее надо динамически создавать число потоков(не меньше одного но и не больше стольки то-мне казалось что тут можно и какими-то стандартными средствами реализовать).

Возник вопрос по маршалингу у WPF. Есть ObservableCollection, в который добавляется элемент. Элемент реализует INotPropChanged. Свойства стреляют изменяются из разных потоков. Соответственно, событие так же выстреливает. Почему WPF не выбрасывает исключение о попытке обратиться не из графического потока, а корректно отображает изменения?

Mikhail Sukhov: Возник вопрос по маршалингу у WPF. Есть ObservableCollection, в который добавляется элемент. Элемент реализует INotPropChanged. Свойства стреляют изменяются из разных потоков. Соответственно, событие так же выстреливает. Почему WPF не выбрасывает исключение о попытке обратиться не из графического потока, а корректно отображает изменения?

ну там же все написано :) это не совсем " ... 2) Обычная реализация INOtifyPropertyChanged ...".

Элемент реализует INotifyPropertyChanged но OnPropertyChanged не вызывается сразу в set{ ... OnPropertyChanged ("...")} а предлагается отдельным методом. Поэтому элемент обновляется на разных потоках а NotifyCollection через определеные интервалы времени зовет OnPropertyChanged для изменившихся полей элемента на GUI потоке

oshelest: Элемент реализует INotifyPropertyChanged но OnPropertyChanged не вызывается сразу в set{ ... OnPropertyChanged ("...")} а предлагается отдельным методом. Поэтому элемент обновляется на разных потоках а NotifyCollection через определеные интервалы времени зовет OnPropertyChanged для изменившихся полей элемента на GUI потоке

Спасибо больше. А вы (я так понял вы и есть автор проекта) планируете сделать это модульно? Сырцы конечно интересны, но мне было бы проще с готовым FW поработать.

А вопрос был чисто из теории. У нас сейчас примеры через обычный ObservableCollection сбайдены с ListView.ItemsSource. Добавлять в ObservableCollection нельзя, делаем GuiAsync. А вот данные в ячейках почему то тикают. Этого понять не могу, так как свойство точно не из графического потока обновляются.