Версия 4.2
Atom
2/12/2013
Mikhail Sukhov


Сейчас в тёмных кузницах S# выплавляется новая версия 4.2. Версия будет содержать ряд революционных изменений, которые я предлагаю обсудить. На вскидку, будут следующие мажорные изменения:


  1. Trader будет переименовал в Connector. Смысл, что SmartTrader и OECTrader - это существующие торговые марки.
  2. Английская локализация. Уже с этой версий и Студией мы планируем начать себя рекламировать в Валиноре.
  3. Новая потоковая модель, которая окончательно поставит точки над i в области синхронизации данных и событий.
  4. Облачное тестирование.


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

Tags:


Thanks: VassilSanych


1 2 3  >
ra81

Avatar
Date: 2/12/2013
Reply


Новая потоковая модель. Это о чем?
Thanks: VassilSanych

VassilSanych

Avatar
Date: 2/12/2013
Reply


Раз уж и так жёстко ломаете API, то наверное стоит проследить за более чёткой типизацией.
Например, Candle сделать дженериком от типа Arg, а то приведение object к нужному типу как-то не правильно и, наверное, не производительно, учитывая боксинг-анбоксинг и т.п.
Thanks: Терпила

Mikhail Sukhov

Avatar
Date: 2/12/2013
Reply


VassilSanych
Раз уж и так жёстко ломаете API, то наверное стоит проследить за более чёткой типизацией.
Например, Candle сделать дженериком от типа Arg, а то приведение object к нужному типу как-то не правильно и, наверное, не производительно, учитывая боксинг-анбоксинг и т.п.


Изначально так и было, а почему потом изменилось - уже не помню. Но можно попробовать еще раз. В любом случае тогда нужен интерфейс. Потому что нужно как-то кастить разные типы свечек между собой.
Thanks:

ra81

Avatar
Date: 2/13/2013
Reply


Как-то дискуссии не выходит. Выходит констатация фактов. Мы изменим и все. А на вопрос про потоковую модель ответа не услышал :(
Thanks: Терпила

pyhta4og

Avatar
Date: 2/13/2013
Reply


ra81
Новая потоковая модель. Это о чем?


Сейчас стратегия выполняется в нескольких потоках. Это происходит от того что стаканы приходят в одном потоке, а сделки в другом. Как результатнеобходимость использования блокировок для доступа к полям например объекта Order.

Чтобы упростить это достаточно выплонять стратегию в одном потоке. Для этого нужна очередь куда буду заносится все события из коннектора, а стратегия будет из этой очереди читать.
Thanks:

ra81

Avatar
Date: 2/13/2013
Reply


pyhta4og
ra81
Новая потоковая модель. Это о чем?


Сейчас стратегия выполняется в нескольких потоках. Это происходит от того что стаканы приходят в одном потоке, а сделки в другом. Как результатнеобходимость использования блокировок для доступа к полям например объекта Order.

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


Я то думал... эрланг... крутизна.
В механизмы того как сейчас все работает я неплохо посвящен. Куча локов и прочей ерунды включая пачку потоков.
А в чем беда использовать SyncronizedTrader?? Он ведь делает ту же самую петрушку? Через что планируется сделать синхронизацию, то есть как будет реализована вот эта самая очередь куда будет все заноситься? Она будет делаться на входе в стратегию для каждой стратегии?? А сам Trader кидать данные будет так же в многопоточном режиме?
Thanks:

Mikhail Sukhov

Avatar
Date: 2/13/2013
Reply


ra81
А в чем беда использовать SyncronizedTrader??


Смысл уйти от локов к лок-фри, а не создавать еще новых локов.
Thanks:

ra81

Avatar
Date: 2/13/2013
Reply


Mikhail Sukhov
ra81
А в чем беда использовать SyncronizedTrader??


Смысл уйти от локов к лок-фри, а не создавать еще новых локов.


Тогда снова вопрос, как будет реализоваться эта процедура? В предыдущем посте вопросы все в общем озвучены. Не просто так спрашиваю. Сам пришел к такой схеме еще в том году. НА входе в страту все события пакуем в очередь и с ними работаем линейно. Интересно решение, которые вы хотите сделать.
Thanks:

Den

Avatar
Date: 2/13/2013
Reply


ra81

Тогда снова вопрос, как будет реализоваться эта процедура? В предыдущем посте вопросы все в общем озвучены. Не просто так спрашиваю. Сам пришел к такой схеме еще в том году. НА входе в страту все события пакуем в очередь и с ними работаем линейно. Интересно решение, которые вы хотите сделать.


Получается, что пока одно событие из очереди полностью не обработано - все стоит и ждет?
Thanks:

ra81

Avatar
Date: 2/13/2013
Reply


Den

Получается, что пока одно событие из очереди полностью не обработано - все стоит и ждет?


Совершенно верно. Вот так нехорошо и плохо происходит :)). Но в случае многопоточной работы происходит совершенно тоже самое. Пока ваш рулес не отпашет, другой рулес сидит и курит в локе, при этом запирает нафиг весь поток. Моя же схема так не делает, событие пакуется в Action и кладется в очередь, лок есь тока в фазе укладки Событий в очередь. Очень незначительный. Надыбаю нормальную неблокирующую очередь будет вообще четко. Пока не парился этим.
Ну и есеесно нет глюков дедлоков итд. Да и бошку греть не надо как разрулить весь этот гемор с потоками, тут надо было профессором чтобы все грамотно сделать. А в одну струю и ламер разберется.

Thanks:
1 2 3  >

Attach files by dragging & dropping, , or pasting from the clipboard.

loading
clippy