Да я как то так ,по мсдну разбирался. и по примерам. я пару статей по
3.5 прочитал, начинал с него. но думаю в этом плане 3.5 и 4 - разницы
никакой нет.
Так а зачем тогда Вы while чиклы пишите? Торговые алгоритмы опираются
на события. Думаю не спроста такие системы как ВетЛаб и Квант
предоставляют именно событийную модель работы. Понятно, что внутри иет
логика последовательная ввиде условий и циклов. Но отправная точна
всегда событие: закончился бар, начался новый, цена превысила, заявка
изменилась и т.д. Может все же идти по пути именно событий? Его до нас
уже протоптали.
Суть в том что все эти танцы с бубном лишь для того, чтобы сварганить
инструмент, в ктором трейдер будет робота РИСОВАТЬ, а рисовать он
может только в виде детерминированых блок-схем. трейдеру будет трудно
рассказать, как пользовать события, почему вмсето того, чтобы на
снятие заявки получить ответ - успешно или неспешн опрошло снятие, он
должен слушать событие, да и мне - разработчику намного удобнее было
бы написать
if(trader.CancelOrder(order))
{
действия при успешном снятии
else
{
при неуспешном
чем отменять заявку, а потом в событии получть заявку, выснять что
именно это за заявка, и какие действия были с ней в прошлом, и что
делать в будущем..
так же намного удобнее проверять заявку
if( status.Done && PartiallyMatched)
чем слушать событие.
а если заявок много, кторые надо проверять? тут уже в событийно
модели начинаются неудобства :)
Вообще конечно, как мне кажется, много пользы прнес бы смешаный режим,
т.к. выстаявлять заявки удобно в асинхронном - и там уже слушать
событии, а вот снимать например лучше в синхроноом - там сразу ясно -
снял или не снял.А так придется блокировки ставить пояле запроса на
снятии, в событии снимать - ну вы сами понимаетет прелести
ассинхронного программирования. :) Извините что так сумбурно :)
P.S. События жутко удобная вещь для написания всяческого рода
индикаторов, тут они выше всяких похвал.
так GuaranteeCancelOrder вроде решение проблемы.А насчет обертки -
буду думать. у меня счас приоритет арбитражер. :) Ежели обертку
синхринизирвоаную намучу - дам вам знать - может сгодится в
стокшарпе :)
Комментарии (12)
Вход или Создать аккаунт, Войдите или зарегистрируйтесь, чтобы оставить комментарий
OrdersChanged пока не придет State Done
мутить блокировки с помощью ManualSetEvent?
Да, видимо придется как в примере SampleConsole раз у вас шаг за шагом... Надо бы глянуть на этот новый WF. Рекомендуете статью для начинающего?
Да я как то так ,по мсдну разбирался. и по примерам. я пару статей по 3.5 прочитал, начинал с него. но думаю в этом плане 3.5 и 4 - разницы никакой нет.
Вы пишите, что там state режима нет. Так что есть.
в смысле state режима? там есть Flowchart
Так а зачем тогда Вы while чиклы пишите? Торговые алгоритмы опираются на события. Думаю не спроста такие системы как ВетЛаб и Квант предоставляют именно событийную модель работы. Понятно, что внутри иет логика последовательная ввиде условий и циклов. Но отправная точна всегда событие: закончился бар, начался новый, цена превысила, заявка изменилась и т.д. Может все же идти по пути именно событий? Его до нас уже протоптали.
Писал развернутый ответ - и тырнет крякнул.
Суть в том что все эти танцы с бубном лишь для того, чтобы сварганить инструмент, в ктором трейдер будет робота РИСОВАТЬ, а рисовать он может только в виде детерминированых блок-схем. трейдеру будет трудно рассказать, как пользовать события, почему вмсето того, чтобы на снятие заявки получить ответ - успешно или неспешн опрошло снятие, он должен слушать событие, да и мне - разработчику намного удобнее было бы написать
if(trader.CancelOrder(order)) { действия при успешном снятии
else { при неуспешном
чем отменять заявку, а потом в событии получть заявку, выснять что именно это за заявка, и какие действия были с ней в прошлом, и что делать в будущем..
так же намного удобнее проверять заявку
if( status.Done && PartiallyMatched) чем слушать событие.
а если заявок много, кторые надо проверять? тут уже в событийно модели начинаются неудобства :)
Вообще конечно, как мне кажется, много пользы прнес бы смешаный режим, т.к. выстаявлять заявки удобно в асинхронном - и там уже слушать событии, а вот снимать например лучше в синхроноом - там сразу ясно - снял или не снял.А так придется блокировки ставить пояле запроса на снятии, в событии снимать - ну вы сами понимаетет прелести ассинхронного программирования. :) Извините что так сумбурно :)
P.S. События жутко удобная вещь для написания всяческого рода индикаторов, тут они выше всяких похвал.
Напрашивается обертка над ITrader (по аналогии с SyncTrader). Может сами сделаете? У меня сейчас приоритеты другие.
так GuaranteeCancelOrder вроде решение проблемы.А насчет обертки - буду думать. у меня счас приоритет арбитражер. :) Ежели обертку синхринизирвоаную намучу - дам вам знать - может сгодится в стокшарпе :)
Насколько я понял, у Вас таких мест уже несколько:
Так что Вам по любому такое надо. Иначе код будете загромождать While Wait и т.д.
Я сейчас отложил воркфлоу немножко,пишу арбитражера по человечески, на событиях. Но обязательно вернусть к этому вопросу.