многопоточность

многопоточность
Atom
6/9/2010
sergun


Скажите, а начиная с какого места Stock# является многопоточным?

Создает ли новые потоки сам QuickTrade, если пользоваться лишь его событиями типа NewTrade и т.п. и не использовать встроенные стратегии?


Tags:


Thanks:


Mikhail Sukhov

Avatar
Date: 6/9/2010
Reply


События вызываются в другом потоке.

Thanks:

sergun

Avatar
Date: 6/9/2010
Reply


т.е. создается всего один доп.поток и в нем вызываются обработчики?

Thanks:

sergun

Avatar
Date: 6/17/2010
Reply


Михаил,

не могли бы уточнить, все ли события QuikTrader работают в одном дополнительном потоке?

В примере SampleConsole событие Connected ожидает появления инструментов (NewSecurities) с помощью ManualResetEvent.

Получается эти два события находятся в разных потоках (иначе бы выполнение блокировалось).

Прав ли я, что в отдельном одном дополнительном потоке исполняется DDE сервер и, соответственно, лишь те события QuikTrader, которые связаны с приходом данных по DDE, а все остальные обработчики (Connected, Disconnected и т.д.) - это основной поток?

Thanks:

Mikhail Sukhov

Avatar
Date: 6/17/2010
Reply


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

Thanks:

sergun

Avatar
Date: 6/17/2010
Reply


Уточню, мой вопрос касается многопоточности именно в неком ядре StockSharp (сам Trader, его обработчики). Вопрос не касается стратегий, менеджера стратегий и т.п.

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

Thanks:

sergun

Avatar
Date: 6/17/2010
Reply


Возник еще один вопрос. Являются ли методы и свойства QuikTrader thread-safe?

Thanks:

Mikhail Sukhov

Avatar
Date: 6/17/2010
Reply


Да, потокобезопасно.

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

Thanks:


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

loading
clippy