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

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

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

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

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


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

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

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

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

Миша, я правильно понимаю, что даже если буду использовать объект синхронизации для стратегии (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()) // (**)
....

}
}

up!

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

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

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

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

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

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

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

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

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

Спасибо!

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



Это точно будет не детерминировано.