Недавно пришлось столкнуться с написанием алгоритма в условиях асинхронности появления входных данных.

Задача заключалось в написании на C# простенького торгового робота, входные данные — биржевые тики, изменения статусов заявок и т.п. —
поступали в мои подписчики на соответствующие события библиотеки, поставляющей данные.

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

Не поделитесь способами моделирования и технологиями реализации подобных задач?

У меня были мысли про цепочки коллбеков, вспомнился Twisted Framework..

Но реализовывать нечто подобное на базе C# event'ов и делегатов я пока не решился.

Здравствуйте, sergunok, Вы писали:

S>Недавно пришлось столкнуться с написанием алгоритма в условиях асинхронности появления входных данных.

S>Задача заключалось в написании на C# простенького торгового робота, входные данные — биржевые тики, изменения статусов заявок и т.п. —
S>поступали в мои подписчики на соответствующие события библиотеки, поставляющей данные.

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

S>Не поделитесь способами моделирования и технологиями реализации подобных задач?

S>У меня были мысли про цепочки коллбеков, вспомнился Twisted Framework..

S>Но реализовывать нечто подобное на базе C# event'ов и делегатов я пока не решился.

Смотри Rx

Здравствуйте, gandjustas, Вы писали:

G>Смотри Rx
Давно интересовался практическими применениями этой либы, может есть у кого случаи успешного применения в рабочих проектах?

Здравствуйте, Aviator, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>Смотри Rx
A>Давно интересовался практическими применениями этой либы, может есть у кого случаи успешного применения в рабочих проектах?

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

А еще один пример вполне успешного применения: http://code.msdn.microsoft.com/RxParsers

Здравствуйте, sergunok, Вы писали:

S>Не поделитесь способами моделирования и технологиями реализации подобных задач?
S>Но реализовывать нечто подобное на базе C# event'ов и делегатов я пока не решился.

Глянь http://rsdn.ru/forum/dotnet/3037674.1.aspx

Автор: Undying
Дата: 27.07.08

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

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Aviator, Вы писали:

A>>Здравствуйте, gandjustas, Вы писали:

G>>>Смотри Rx
A>>Давно интересовался практическими применениями этой либы, может есть у кого случаи успешного применения в рабочих проектах?

G>У меня есть пример успешного применения в нерабочем проекте Переписал несложный сервер на Rx, код уменьшился раз 5, но в продакшн не пошло.

Интересно бы посмотреть за счёт чего такое уменьшение кода. Может просто рефакторинг?

Здравствуйте, Aviator, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Aviator, Вы писали:

A>>>Здравствуйте, gandjustas, Вы писали:

G>>>>Смотри Rx
A>>>Давно интересовался практическими применениями этой либы, может есть у кого случаи успешного применения в рабочих проектах?

G>>У меня есть пример успешного применения в нерабочем проекте Переписал несложный сервер на Rx, код уменьшился раз 5, но в продакшн не пошло.

A>Интересно бы посмотреть за счёт чего такое уменьшение кода. Может просто рефакторинг?

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

Здравствуйте, sergunok, Вы писали:
....
S>Пришлось городить нечто вроде огромного конечного автомата.
S>Кстати еще было нужно мочь сериализовывать текущее состояние обработки и потом его восстанавливать.

S>Не поделитесь способами моделирования и технологиями реализации подобных задач?

WWF

Большое спасибо!!!!

Классная штука. Многие вопросы решит. И 100% пригодится.

Кстати сами применяли эту штуку для какой-нибудь подобной обработки событийных данных?
Кроме Lab'ов есть достойные материалы?

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

G>Смотри Rx

Здравствуйте, sergunok, Вы писали:

S>Большое спасибо!!!!

S>Классная штука. Многие вопросы решит. И 100% пригодится.

S>Кстати сами применяли эту штуку для какой-нибудь подобной обработки событийных данных?
S>Кроме Lab'ов есть достойные материалы?
Лучше всего видео на их сайте смотреть, там стараются толково объяснить базовые вещи, а все остальное легко делается после этого.

S>Очень интересно как в ней моделировать действия, состояющие из нескольких событий (эдакие длинные транзакции)
action1.SelectMany(action2) или from a in action1 from b in action2

S>и описывать их псевдопараллельную обработку.
.Join, .Amb итд

Здравствуйте, gandjustas, Вы писали:
A>>Интересно бы посмотреть за счёт чего такое уменьшение кода. Может просто рефакторинг?
G>За счет монад, неявного протаскивания контекста, наличия замыканий и массового использования лямбд.

Т.е. код стал сильно похож на функциональный? А читаемость кода и удобство дебага не слишком сильно пострадало?

Здравствуйте, gandjustas, Вы писали:

A>>Интересно бы посмотреть за счёт чего такое уменьшение кода. Может просто рефакторинг?

G>За счет монад, неявного протаскивания контекста, наличия замыканий и массового использования лямбд.

Несколько примерчиков можно кинуть?

Здравствуйте, Aviator, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:
A>>>Интересно бы посмотреть за счёт чего такое уменьшение кода. Может просто рефакторинг?
G>>За счет монад, неявного протаскивания контекста, наличия замыканий и массового использования лямбд.

A>Т.е. код стал сильно похож на функциональный?
Ну да

A>А читаемость кода и удобство дебага не слишком сильно пострадало?

Ну учитывая что код был покрыт тестами и отлажен до переписывания, то не пострадало вообще.

Что касается писания на Rx с самого начала, то удобство отладки и тестирования только увеличивается, так IObservable очень легко мокать, в отличие от реализации state machine на коллбеках, а в самом Rx реализовано очень много комбинаторов, которые заменяют тучу "водопроводного" кода.

Здравствуйте, Aviator, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

A>>>Интересно бы посмотреть за счёт чего такое уменьшение кода. Может просто рефакторинг?

G>>За счет монад, неявного протаскивания контекста, наличия замыканий и массового использования лямбд.

A>Несколько примерчиков можно кинуть?

http://rsdn.ru/forum/dotnet/3836285.1.aspx

Автор: gandjustas
Дата: 08.06.10

Тоже самое на TPL
http://rsdn.ru/forum/dotnet/3836050.1.aspx

Автор: gandjustas
Дата: 08.06.10

Для разминки можете попробовать повторить без Rx и TPL

Описать на нем автомат? Заставить реагировать на события?
Чем он хорош в данной ситуации?

А>WWF

Здравствуйте, sergunok, Вы писали:

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

Я все так пишу, мне привычно

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

Здравствуйте, Pzz, Вы писали:

Pzz>Но вы можете выделить логику в отдельный поток. Соответственно, callback'и кладут куда-нибудь данные, будят этот поток и ждут ответа. Поток крутится в цикле ожидания запросов, получив запрос, он его обрабатывает, кладет куда-нибудь ответ, будит соответствуюший callback и засыпает в ожидании нового запроса.

А смысл, если есть отличное решение в виде Rx? Если Rx чем-то не устраивает, то можете здесь написать.

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

Приведу упрощенный пример.

API, которое имеется:

3 разновидности событий:
- биржевой тик Ticked(price) - тек. рыночная цена
- заявка выполнена(полностю или частично) OrderMatched(order) 
- заявка снята OrderCanceled(order)

2 типа воздействий
- выставить заявку RegisterOrder(order)
- снять заявку CancelOrder(order)

Алгоритм к примеру такой (утопичный, но простой).
Всегда держать свою заявку на рынке с ценой на 1% выше рынка.

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

У меня в голове сразу возникает понятие переменной с состояниями типа:
— заявка выставлена
— жду снятия

И куча if'ов в трех коллбеках, в привязке к состоянию.

Мысль про цепочки коллбеков у меня возникала (уже написал, навеяно питоновским twisted) и их поднавешивания в run-time.

А вот как тут поможет RX?

Я создаю три Observable коллекции, привязываю их к моим событиям (кстати, насколько понял RX требует наличия аргумента наследника от System.EventArgs). Дальше подписываюсь на эти коллекции и собственно говоря снова возникают те же самые обработчики и переменная состояния, но уже в контексте подписки..


Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Pzz, Вы писали:

Pzz>>Но вы можете выделить логику в отдельный поток. Соответственно, callback'и кладут куда-нибудь данные, будят этот поток и ждут ответа. Поток крутится в цикле ожидания запросов, получив запрос, он его обрабатывает, кладет куда-нибудь ответ, будит соответствуюший callback и засыпает в ожидании нового запроса.

G>А смысл, если есть отличное решение в виде Rx? Если Rx чем-то не устраивает, то можете здесь написать.

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

Сериализация, останов, десериализация также нужны для данной задачи.

Здравствуйте, sergunok, Вы писали:

S>Кстати, а можно сериализовать вместе с полями объекта установленные на данный момент обработчики да еще и контекст лямбда-выражений?
Конечно нет.

S>Сериализация, останов, десериализация также нужны для данной задачи.
Упаси бог, а зачем?