Экспорт стакана - многопоточность
Atom
06.10.2011


Здравствуйте,

не могли бы вы ответить на пару следующих вопросов:

1. Допустим есть несколько стратегий: "стратегия_1", "стратегия_2", ..., "стратегия_N". Логика каждой из них обслуживается отдельным потоком,
таким образом имеется N потоков, каждый из которых соответствует своей стратегии. Каждый поток реагирует на изменение цены любого инструмента,
принадлежащего какому-то набору (каждый поток следит за своим набором инструментов). Подскажите, пожалуйста, какой метод донесения информации до каждого
из потоков является самым правильным и быстрым? Логика, которую я имею в виду в этом вопросе: если мы сначала вызываем trader.RegisterQuotes
для всех инструментов, с которыми будут работать ВСЕ наши стратегии, а потом подписываемся на событие trader.QuotesChanged, то изменение в стакане для любого из
ранее зарегестрированных инструментов приведет к срабатыванию данного события. Но, насколько я понимаю, все подписчики на данное событие будут исполняться
только в одном потоке. Это верное утверждение? Если да, то как лучше всего реализуется идея "сколько стратегий, столько и тредов"? А если нет, то как
исполнять обработчики данного события в разных тредах (как подписать тред на событие "изменение стакана")?

2. Если говорить только о скорости, то как быстрее получать информацию о "цене" инструмента: подписаться на таблицу всех сделок и фильтровать каждую сделку
на предмет того или иного инструмента или экспортировать стаканы тех инструментов, за которыми хотим следить и подписаться на изменение данных в стакане?

Заранее благодарю за ответы.

Теги:


Спасибо:


Mikhail Sukhov

Фотография
Дата: 06.10.2011
Ответить


_maratrus_ Перейти
Подскажите, пожалуйста, какой метод донесения информации до каждого из потоков является самым правильным и быстрым?


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

_maratrus_

Фотография
Дата: 07.10.2011
Ответить


Mikhail Sukhov Перейти
_maratrus_ Перейти
Подскажите, пожалуйста, какой метод донесения информации до каждого из потоков является самым правильным и быстрым?


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


1. Согласен, что вопрос получился несколько запутанным. Позвольте его упростить. Хочется, чтобы при изменении данных в стакане, каждый из потоков
посмотрел, в каком именно стакане это произошло, ответственен ли данный поток за этот инструмент и если да, проделал какие-нибудь действия. Как
это правильно делать в парадигме S# <---> Quik. Надеюсь, так стало понятнее?

2. По второму вопросу необходимы ли какие либо комментарии?
Спасибо:

Mikhail Sukhov

Фотография
Дата: 07.10.2011
Ответить


_maratrus_ Перейти
1. Согласен, что вопрос получился несколько запутанным. Позвольте его упростить. Хочется, чтобы при изменении данных в стакане, каждый из потоков
посмотрел, в каком именно стакане это произошло, ответственен ли данный поток за этот инструмент и если да, проделал какие-нибудь действия. Как
это правильно делать в парадигме S# <---> Quik. Надеюсь, так стало понятнее?

2. По второму вопросу необходимы ли какие либо комментарии?


1. Понятнее. Но это вопрос из серии "как мне сделать так, чтобы все работало как нужно". Путь тут только один - пишите код правильно, чтобы можно было понять какой именно стакан. Парадигма S# относится к этому вопросу косвенно.

2. Вопрос тоже мягко говоря абстрактный. Цена сделки - это цена сделки. Цены в стакане - это цены заявок. Поймите, что лучше для вашего алгоритма, и выберите. Раз вы задаете подобные вопросы я бы на вашем месте пока не беспокоился о скорости. Главное, хоть как-то сделайте.
Спасибо:

Alexander

Фотография
Дата: 07.10.2011
Ответить


А разве стоит использовать Квик если нужна действительная быстрая работа алгоритма? :)
Спасибо:

_maratrus_

Фотография
Дата: 07.10.2011
Ответить


Mikhail Sukhov Перейти

1. Понятнее. Но это вопрос из серии "как мне сделать так, чтобы все работало как нужно". Путь тут только один - пишите код правильно, чтобы можно было понять какой именно стакан. Парадигма S# относится к этому вопросу косвенно.


1. Позвольте мне еще раз уточнить вопрос, чтобы он уж точно имел отношение к S#. Обработчики события "Изменение стакана одного из ранее зарегистрированных инструментов" всегда исполняются в одном треде?

Mikhail Sukhov Перейти

2. Вопрос тоже мягко говоря абстрактный. Цена сделки - это цена сделки. Цены в стакане - это цены заявок. Поймите, что лучше для вашего алгоритма, и выберите. Раз вы задаете подобные вопросы я бы на вашем месте пока не беспокоился о скорости. Главное, хоть как-то сделайте.


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

Alexander Mukhanchikov

А разве стоит использовать Квик если нужна действительная быстрая работа алгоритма? :)


Подловили :) Нет, квик не единственная используемая схема. Но есть потребность что-то реализовать и в квике. Хотелось бы реализовать наилучшее из возможных решений :)


Спасибо:

Mikhail Sukhov

Фотография
Дата: 07.10.2011
Ответить


_maratrus_ Перейти

1. Позвольте мне еще раз уточнить вопрос, чтобы он уж точно имел отношение к S#. Обработчики события "Изменение стакана одного из ранее зарегистрированных инструментов" всегда исполняются в одном треде?


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

_maratrus_ Перейти

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


Это все зависит от робота. S# тут постольку-поскольку.
Спасибо: _maratrus_


Добавить файлы через драг-н-дроп, , или вставить из буфера обмена.

loading
clippy