The calling thread cannot access this object because a different thread owns it.

[NinjaTrader_Brett]

Yep. Thanks.

[NJA_MC]

Went though this with Development and Product Management team was just educated that yes we should be Freezing brushes due to the multi-threaded nature of NinjaTrader.

This has impact with DrawingTools, Setting Plots, Setting Lines, and OnRender method.

I will start adding documentation this week to make this more clear, thanks guys for running through this.

Brett,

I am sure you guys are on this, but just wanted to post PENs should be frozen as well. They are based upon the Freezable class as well.

[koganam]

Never said compilation ( I think that was incorrectly pulled from another poster). Will just be a runtime exception caught and logged just like any other exception occurring in a NS object so we are consistent with how we handle.

Ah! Excuse my stupidity, please.

[NinjaTrader_Brett]

Never said compilation ( I think that was incorrectly pulled from another poster). Will just be a runtime exception caught and logged just like any other exception occurring in a NS object so we are consistent with how we handle.

[koganam]

Problem is not one thread is used in the majority of situations.

OnBarUpdate, OnStateChanged, OnMarketData, OnMarketDepth is all multi-threaded. Sure the render call is the only one thats not but its better to freeze then have the majority of clients run into intermittent issues is current thinking.

Brett, your statement is a bit ambiguous. There is a difference between the various events each potentially running on a different thread each, and each of them running on multiple threads.

In the former situation, scope considerations would mean that a brush defined in one event would not be available outside it anyway, and if each event is running on a single thread (albeit a different thread from the other events), then, again, Freeze()ing may need to be optional. Of course, if the latter is the case, then you are absolutely correct.

Regardless, it might be useful to have a warning if any brush is not Freeze()d. I am just not sure that an enforced compilation failure is the correct solution. Any brush declared in class scope, on the other hand, should probably be mandatorily Freeze()d, and so result in an enforced compilation failure.

[NJA_MC]

Problem is not one thread is used in the majority of situations.

OnBarUpdate, OnStateChanged, OnMarketData, OnMarketDepth is all multi-threaded. Sure the render call is the only one thats not but its better to freeze then have the majority of clients run into intermittent issues is current thinking.

Brett,

I agree, you need something, I had been chasing this bug for about 8 days! A compiler failure or atleast a warning or log error, something is required to notify the coder of a Multi-Tasking error.

After I thought I got them all, I found another Brush used deeper in the code, a compile warning or failure would have helped.

[NinjaTrader_Brett]

Plus if your in OnRendner you've committed to handling things yourself anyways. Could always handle yourself instead. (Don't use Draw. methods etc.)

[NinjaTrader_Brett]

Problem is not one thread is used in the majority of situations.

OnBarUpdate, OnStateChanged, OnMarketData, OnMarketDepth is all multi-threaded. Sure the render call is the only one thats not but its better to freeze then have the majority of clients run into intermittent issues is current thinking.

[koganam]

Furthermore, I will ask development to terminate the NS and log an error explaining to you that you needed to freeze the brush if a non-freezed brush is passed in. Which should help for future cases as well.

Hm. That may be overkill. It is only necessary to freeze brushes that may possibly be accessed across threads. If the brush is confined to one thread, such as being defined in OnRender() for example, there may be no need to freeze it.

This becomes especially important if we intend to change the color or any other properties of the brush, (as for example, drawing multiple lines of text that have different colors or backgrounds). Granted that we can always Clone() the brush and so in a roundabout fashion change the brush properties, it may sometimes simply be preferable to modify the brush directly.

Just my $0.02.

[NinjaTrader_Brett]

Furthermore, I will ask development to terminate the NS and log an error explaining to you that you needed to freeze the brush if a non-freezed brush is passed in. Which should help for future cases as well.

[NinjaTrader_Brett]

Went though this with Development and Product Management team was just educated that yes we should be Freezing brushes due to the multi-threaded nature of NinjaTrader.

This has impact with DrawingTools, Setting Plots, Setting Lines, and OnRender method.

I will start adding documentation this week to make this more clear, thanks guys for running through this.

[NJA_MC]

Grrrr...

Okay, I am not getting the same error, getting a different one intermittently... So not quite out of the woods yet:

 2015-06-03 16:26:05:034 ERROR: Failed to call 'Add' method: Write lock may not be acquired with read lock held. This pattern is prone to deadlocks. Please ensure that read locks are released before taking a write lock. If an upgrade is necessary, use an upgrade lock in place of the read lock.

[NJA_MC]

Try freezing the new SolidBrush() first.

Wow!

This is a biggie... I tried this and think it may have fixed a lot of other intermittent issues. This is important to discuss in the NinjaScript reference!

"Freezing" the brushes seems to have cleaned up and closed this issue.

[sledge]

I had to Google freezing to see what was going on.
Came across this, which looks like it applies to here?

https://msdn.microsoft.com/en-us/library/ms750509%28v=vs.110%29.aspx

[-=Edge=-]

We probably need to have this in the NT documentation? No?

Or a simple reference sample.. Would have definitely saved me some time trying to debug that.. Simple fix though, thanks again!