Signals
Signals are generally produced in #1 and submitted for immediate synchronous execution or can be put in a queue -and executed when possible. This Signal execution then calls into the TradeWorkflowState
TradeWorkflowState
Order Submission, position open close, exits are handled here.
Calls into TradeWorkflowState are not queued and called on a bg thread etc - they are event driven
There are a number of reasons for this..
1Timely execution no delay or additional overhead
2 Reliability of parallel patterns in NT8 - limitations
Reliable execution context is OnBarUpdate and OnMarketData and the othe events
A dispatcher timer could be used as well - and it needn't run all the time I can be kicked off to return back after an interval and shutdown. OnMarketData and a timer could be employed - but in preference try OnMarketData first.
What type of Q?
Typically we use enqueue enums to use to call into a method... vanilla. and using a state machine/workflow to assist.
This should likely be a concurrentqueue<>
Other Patterns
A more exciting way of working - A generic "action task" where we can enQ methods on for calling in turn, and use parallel execution until all tasks return etc - instead of a workflow. This was fantastic fun - but NT8 stopped responding or the calls never came back - maybe that was sloppy coding or the NT8 "MT" limitation - I will post that model later.
Summary
So for using Queues and handling pseudo parrallel workload patterns
im thinking a Q of a enumerated actions that could be processed by OnMarketUpdate pushing or via a dispatcher timer -
as my other attempts did not end well :-) and that might be limitations in NT8 - where the patterns worked fine in a benchtest but not within NT8 or it might be some caveats needed to be considered -however NT8 multithreading guidance was taken down as it was found to be unreliable for inclusion within NinjaScript.
Main Events to consider
Signals Signals are generally produced in #1 and submitted for immediate synchronous execution or can be put in a queue -and executed when possible. This Signal execution then calls into the TradeWorkflowState
TradeWorkflowState
Order Submission, position open close, exits are handled here. Calls into TradeWorkflowState are not queued and called on a bg thread etc - they are event driven There are a number of reasons for this..
1Timely execution no delay or additional overhead
2 Reliability of parallel patterns in NT8 - limitations
Reliable execution context is OnBarUpdate and OnMarketData and the othe events A dispatcher timer could be used as well - and it needn't run all the time I can be kicked off to return back after an interval and shutdown. OnMarketData and a timer could be employed - but in preference try OnMarketData first.
What type of Q? Typically we use enqueue enums to use to call into a method... vanilla. and using a state machine/workflow to assist. This should likely be a concurrentqueue<>
Other Patterns A more exciting way of working - A generic "action task" where we can enQ methods on for calling in turn, and use parallel execution until all tasks return etc - instead of a workflow. This was fantastic fun - but NT8 stopped responding or the calls never came back - maybe that was sloppy coding or the NT8 "MT" limitation - I will post that model later.
Summary So for using Queues and handling pseudo parrallel workload patterns im thinking a Q of a enumerated actions that could be processed by OnMarketUpdate pushing or via a dispatcher timer - as my other attempts did not end well :-) and that might be limitations in NT8 - where the patterns worked fine in a benchtest but not within NT8 or it might be some caveats needed to be considered -however NT8 multithreading guidance was taken down as it was found to be unreliable for inclusion within NinjaScript.