Многопоточность-однопоточность
Atom
28.07.2011


Михаил & co, приветствую!

Возник такой вопросик. Допустим мне, из архитектурных соображений (возьмем это за данное), хочется, чтобы:
1. все события любой, отдельно взятой стратегии возникали и обрабатывались не более чем одной нитью
2. все разделяемые и модифицируемые данные в рамках стратегии: заявки, инструменты оставались неизменными по ходу работы обработчиков стратегии
(например, хочется быть уверенным, что по ходу работы обработчика NewOrder, объекты-заявки, пришедшие в нем, не изменятся или что не изменится BestBid/Ask).

Самих стратегий м.б. много, несколько десятков.
Мне известен путь "в лоб" для достижения цели №1 - lock в обработчиках на какой-то объект синхронизации, свой для каждой стратегии, но не очень понятно насколько это хорошо с т.зр. производительности при большом числе стратегий.
Как добиться цели №2 от S# я не знаю.

Что-нибудь посоветуете по этим топикам?

Спасибо!

PS. Вопрос не про QUIK, про любые адаптеры S#.

Теги:


Спасибо:




1 2  >
President

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


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

re: "lock в обработчиках на какой-то объект синхронизации, свой для каждой стратегии, но не очень понятно насколько это хорошо с т.зр. производительности при большом числе стратегий"
вы же локи будете делать в рамках одной стратегии так что другие стратегии не будут аффектиться.

2.
если бы мне было это нужно то я бы делал лок в начале евента, копировал бы в локальные переменные то что мне нужно оставить неизменным, отпускал бы лок и далее работал бы с локальными переменными.
но мне кажется что это не самый лучший подход, т.к. в ситуации когда вы могли бы обработать наиболее последний BestBid/Ask и следовательно быть "ближе к рынку" вы будете немного запаздывать.
Спасибо:

sergun

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


President GoTo
1.
я помню как специально делал выводы ThreadID чтобы понять из каких потоков меня дергают и увидел что айдишники разные - т.о. я сделал вывод что события дергаются из пула потоков.
наверное было бы хорошо иметь возможность этот пул настраивать (например, указывать количество потоков, а в идеале и переопределять диспетчер чтобы например приоритезировать вызовы - например сделать для NewMyTrade максимальный приоритет - хотя думаю выигрыш будет совсем ничтожный)


Все равно непонятно как оно организована в "ядре". Ожидают ли нити, занимающиеся экспортом данных, возврата управления от нити из пула, есть ли этот пул. Дело ясное, что дело темное.

President GoTo

2.
если бы мне было это нужно то я бы делал лок в начале евента, копировал бы в локальные переменные то что мне нужно оставить неизменным, отпускал бы лок и далее работал бы с локальными переменными.
но мне кажется что это не самый лучший подход, т.к. в ситуации когда вы могли бы обработать наиболее последний BestBid/Ask и следовательно быть "ближе к рынку" вы будете немного запаздывать.

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

Михаил, прокомментируйте plz эти моменты.
Спасибо:

Mikhail Sukhov

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


sergun GoTo
Михаил, прокомментируйте plz эти моменты.


Да с тех пор было столько переделок без меня, что уже сам не знаю, как некоторые вещи работают. Что касается событий, то не нужно зашиваться на то, одним потоком идет обработка, несколькими, или пулом. Многое зависит от шлюза, да и не факт, что от версии к версии может не измениться. Рассчитывайте на худший сценарий - разные потоки для каждого события.

Что касается разделяемых данных, то они так же модифицируются параллельно.
Спасибо:

sergun

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


Mikhail Sukhov GoTo
Что касается разделяемых данных, то они так же модифицируются параллельно.

Миша, я правильно понимаю, что даже если буду использовать объект синхронизации для стратегии (strategyLock в примере)
все равно из-за параллельной модификации разделяемых объектов "ядром" в точках (*) и (**) поля order могут отличаться?

А как быть? Crying

void OrderChangedHandler(IEnumerable<Order> orders)
{
lock(this.strategyLock)
{
var order = orders.FirstOrDefault(o => o.Security.Code == "LKOH");
if(order == null)
return;

if(order.Balance > 10) // (*)
...

...


if(order.IsDone()) // (**)
....

}
}
Спасибо:

sergun

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


up!

хотелось бы дообсудить этот момент..

таким ли будет поведение в данной ситуации?

мешает ли это кому-нибудь еще?
Спасибо:

vader

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


да, мне мешат, если я вас правильно понял.
У меня такая ситуация.
стратегия содержит два правила ,одно для совершения сделок, другая контролирует количество купленных/проданных лотов.
и так получается, что пока метод, связанный со вторым правилом произодит подсчеты и определяает не пора ли останавливать стратегию, метод отвечающий за совершение сделок успевает вызватся несколько раз и отправить заявок больше чем нужно.
Можно ли как-то заблокировать вызов других методов(или ожидание исполнения условий) ,пока идет работа метода, осущестляющего контроль сделок?
Спасибо:

Mikhail Sukhov

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


sergun GoTo
А как быть? Crying


Пока никак. Специфика дизайна. Из отпуска приедет pyhta4og, решим, можно ли тут что-то исправить малой кровью.
Спасибо:

sergun

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


vader GoTo
да, мне мешат, если я вас правильно понял.
У меня такая ситуация.
стратегия содержит два правила ,одно для совершения сделок, другая контролирует количество купленных/проданных лотов.
и так получается, что пока метод, связанный со вторым правилом произодит подсчеты и определяает не пора ли останавливать стратегию, метод отвечающий за совершение сделок успевает вызватся несколько раз и отправить заявок больше чем нужно.
Можно ли как-то заблокировать вызов других методов(или ожидание исполнения условий) ,пока идет работа метода, осущестляющего контроль сделок?

Эта задача решается примитивами синхронизации. Она соответствует п.1 из моего поста.
Спасибо:

sergun

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


Mikhail Sukhov GoTo
sergun GoTo
А как быть? Crying


Пока никак. Специфика дизайна. Из отпуска приедет pyhta4og, решим, можно ли тут что-то исправить малой кровью.

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

оно реально тормозило и пришли к решению многонитевой обработки?

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

Спасибо!
Спасибо:

Mikhail Sukhov

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


sergun GoTo

оно реально тормозило и пришли к решению многонитевой обработки?


Оно само так возникло.

sergun GoTo

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


Это точно будет не детерминировано.
Спасибо:
1 2  >

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

loading
clippy