Multiple OnBarUpdate active

[zweistein]

This is correlated to a previous post.

Is it possible that OnBarUpate() is concurrently running several times or is each OnBarUpdate() returning to NT and then NT calls again into OnBarUpdate()

My point: what happens if your Close[0] is updated every 1/10 of second but OnBarUpdate() calculated 0,5s every now and then.

Will NT wait for OnBarUpdate to return or will it call into it several times?


Best regards
Andreas

[NinjaTrader_Bertrand]

This would depend on your CalculateOnBarClose setting Andreas - http://www.ninjatrader-support.com/H...BarClose1.html

[zweistein]

offcourse I have CalculateOnBarClose=false;

So in my OnBarUpdate().
I do set a variable
noFurtherOrders=true once SetProfitTarget is called.


But! Now that multiple calls are concurrently possible into OnBarUpdate():

Then it could be that I set noFurtherOrders=true in one instance of OnBarUpdate and maybe another instance is also running and possible behind the code check for noFurtherOrders and would then initiate another Order.

It might also be necessary to specify the volatile attribute for noFurtherOrders to avoid compiler optimisations that are not aware of this concurrent OnBarUpdate() instance reality.

Any enlightments here?

Best regards

[zweistein]

to understand better let us think of an extreme case:

We have 100000 ticks a second hence we have 100000 calls into OnBarUpdate() a second.

Now we assume OnBarUpdate() takes 1 Second to calculate.

Hence we have 100000 instances of OnBarUpdate() running.
This for sure would cause a stack overflow error in .NET

How is this handled by NT?

Will you limit to a certain number of instances?

[NinjaTrader_Bertrand]

Hi Andreas, thanks for clarifying - we'll get back to you on this.

[NinjaTrader_JoshP]

If it takes you awhile to process OnBarUpdate(), Windows will queue any events in a loop.

[zweistein]

Windows will queue...

but how does NT behave? Will the NT internal scheduler wait for OnBarUpdate() to return or not? Will NT send multiply OnBarUpdate() calls without waiting for a return of each first?


Best reagrds

[NinjaTrader_Dierk]

NT does not queue nor schedule nor filter/aggregate events. Whatever is triggered by Window will be processed by NT. Please consults the MS docs for details on windows event processing.

[zweistein]

Hello Dirk und guten Morgen,


I do not understand what Windows has to do with OnBarUpdate() ?

The Windows OS will never initiate such a call, it will only receive it and put it in the message queue. Windows will not omitt elements from the message queue.
The OnBarUpdate() must origin from NT and my question concerns the logic of the handling within NT

Andreas

[NinjaTrader_Dierk]

All real-time NT and NinjaScript events are ultimately triggered by windows events. NT would trigger these events as windows triggers it's events. There is no buffer/filtering/aggregating whatsoever in NT.

[zweistein]

To find out I tried the following code: Basically I force the code to wait 5 seconds before returning control to NT.

protectedoverridevoid OnBarUpdate()
{
if(Historical) return;
if(u>5) return;
Print(DateTime.Now.ToString()+"entering");
Thread thread = new Thread(
delegate(){int k=0;
for(int i=0;i<5;i++){
Thread.Sleep(1000);
k++;}});
thread.Start();
Print(DateTime.Now.ToString() + "started");
thread.Join();
Print(DateTime.Now.ToString()+"exiting");
u++;
}



The result is:

17/05/2009 7.46.30entering
17/05/2009 7.46.30started
17/05/2009 7.46.35exiting
17/05/2009 7.46.35entering
17/05/2009 7.46.35started
17/05/2009 7.46.40exiting
17/05/2009 7.46.40entering
17/05/2009 7.46.40started
17/05/2009 7.46.45exiting
17/05/2009 7.46.45entering
17/05/2009 7.46.45started
17/05/2009 7.46.50exiting
17/05/2009 7.46.50entering
17/05/2009 7.46.50started
17/05/2009 7.46.55exiting
17/05/2009 7.46.55entering
17/05/2009 7.46.55started
17/05/2009 7.47.00exiting

Hence OnBarUpdate() is called only one after the other, no concurrent instances detected.

=> my problem with SetStopOrder has its origin somewhere else.

[NinjaTrader_Dierk]

I'm not exactly sure why you went the long way instead of just coding

Thread.Sleep(5000)

in your OnBarUpdate method. This would have blocked NT for 5 secs as well (which you NEVER should do though).

Anyway, exploring the details of standard C# coding unfortunately would be beyond what we could provide support for.

[zweistein]

i tried thread.sleep first,but i forgot historical. so everything locked up.
my idea was to put sleep in a different thread and in the main thread i keep the message pump active.this does join.

my actual question is about orders and i can only test with real executions,hence tomorrow

[NinjaTrader_Dierk]

>> this does join.
Incorrect. It blocks the waiting thread (= app main thread: message loop would we blocked as well). Please consult the MS docs for proper usage. I also recommend only using those advanced concepts you fully understand and starting simple as possible to isolate the cause of trouble, before getting into the more trickier stuff.

[zweistein]

Actually I get from

http://msdn.microsoft.com/en-us/library/95hbf2ta.aspx

it says:
.NET Framework Class Library
Thread..::.Join Method
Blocks the calling thread until a thread terminates, while continuing to perform standard COM and SendMessage pumping.

From my understanding Sleep is also different from Suspend in several ways as with Sleep the thread is stopped immediately why with Suspend the thread is stopped at a "safe" place. Thread.Join will use Suspend


I did not investigate further but I assumed that a PeekMessage/ProcessMessage style loop would be used. (PeekMessage is old Windows C Api style)

If you want to help me (as the origin of my question is to find out wether OnBarUpdate() can be called a second time while the first call has not yet returned control to NT, can you give more information please?

Thank you

andreas