locks and Account.Positions

[ntbone]

The code in PositionAvgPrice.cs, PositionSize.cs, ProfitLoss.cs and UnrealizedProfitLoss.cs reference Account.Positions. When they do, they put a lock on Account.Positions.

I assume that code in NinjaTrader locks on this collection whenever it is adding/removing positions from the collection. I also need to iterate over all the positions but I want it do it from an event handler connectioned to Account.PositionUpdate.

How do I know that NinjaTrader will never have already acquired a lock on this collection when it calls my event handler? If there is some condition for which this event handler could be called with the lock already in place then the code will deadlock.

[NinjaTrader_Jim]

Hello ntbone,

Thanks for your post.

When accessing these collections we should follow what is presented in the Help Guide, and also what you see in our system indicators. (Use lock before accessing the collection.)

https://ninjatrader.com/support/helpGuides/nt8/positions_account.htm

Accessing in Account.PositionUpdate may be a different case, but I have not heard of any dead lock scenarios to provide much additional detail. Are you stating that you are encountering dead locks here? If you attach a small example showing how the deadlock is encountered, we may be able to provide additional insight.

Speaking objectively, and not just in terms of NinjaTrader, it is possible that a thread releases a lock and then the lock gets taken again almost immediately after. For cases like that, you could try using a passthrough lock like Monitor.TryEnter which will allow execution to continue if the lock cannot be taken. If it is crucial that the lock/information be obtained, you could consider combining with a loop to attempt grabbing the lock several times if it could not be captured the first time.

Publicly available information on Monitor.TryEnter can be found below.

https://docs.microsoft.com/en-us/dotnet/api/system.threading.monitor.tryenter?view=netframework-4.8

We look forward to assisting.

[hedgeplay]

Hi ntbone,

When the market would hit an impulse I also had significant deadlock issues when using locks on Account.Positions as described in the example in the guide.

"I assume that code in NinjaTrader locks on this collection whenever it is adding/removing positions from the collection."

I came to this same conclusion.

So what did I do?

I first tried the route of adding more complexity around locking but eventually concluded with an overall design principle:

Execute a bias against adding more wait states into repetitive event operations.

"Keep it Simple" ... what I am doing now.

1) Switched calls to Account.Positions from tick data series to seconds based data series to reduce the likelihood that a market impulse drives a sudden flury of competitive locking activity on Account.Positions from both position changes and my own calls to Account.Positions.

2) The market might be stalled more frequently than it is moving. Lets use this to our advantage. Only allow calls like you mention above with the market is stalled and mostly likely there will be no competitive locking from NT8's underlying operations. Something simple like:

"If tickspeed is less than 35% of tickspeed's short moving average allow calls to Account.Positions using methods recommend by the NT team."

HedgePlay

[ntbone]

Deadlocks can be very hard to detect in the first place, let alone reproduce.

In response to NinjaTrader_Jim's response, I assume you have access to NinjaTrader source code. It would be helpful to know if a lock is being held on Account.Positions whenever the event handler Account.PositionUpdate is called. As long as a lock is not in place I should not run into a deadlock.

Consider the following

Account account = null;

lock(account.Positions)
{
    ///...
    account.PositionUpdate(account, args);     // with the lock on account.Positions already in place, if
                                               // anyone who is responding to this event also calls lock(account.Positions)
                                               // the dead lock will occur since the lock is already in place and won't be
                                               // freed up until the event handlers return. The event handlers can't return
                                               // because they are waiting on the same lock.
}

The help guides provide very little details on which collections should have a lock on them before they are accessed. I have relied mostly on finding it in the code available to me. Having a list in the help that indicates which collections should be locked before accessing would be helpful.

My general practice is to lock on collections, copy the collections and release the lock, then operate on the copied collection. This minimizes the amount of time I have the lock held, but doesn't necessarily mitigate the problem above with a deadlock.

[NinjaTrader_Jim]

Hello ntbone,

I do not have access to NinjaTrader source code, so I could not curate a list of collections that are locked and when.

In general, a lock would be needed to prevent a collection from being modified while it is being accessed elsewhere. If there is a potential that the collection could be modified somewhere else at the same time your code is trying to access the collection, a lock should be used.

So I can answer your account.PositionUpdate question accurately, I am asking a member of Quality Assurance who would have access to the source code.

I can confirm: a lock is used on account.Positions in this case.

I assume this would carry the need to lock the Positions collection, but I will update this post after I have received confirmation.