Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
I have shared routines between different indicators, even strategies.
I've created a new .cs file in the Indicator folder with it's own "namespace AAGlobal" and "public class Methods". Then inside this are the individual methods. The Ninja editor opens this "Indicator" and it compiles fine.
The methods in this class I have defined as "public static", and these can be referenced successfully (i.e. compiled) in other Indicators and Strategies when referenced with using AAGlobal and then qualifying the method in the calling statement.
"
My question is....what happens if multiple indicators and strategies execute this code at "the same time"?
Would it be better to not have the methods declared "static", and instantiate the method in the calling program?
Thanks
Can you help answer these questions from other members on NexusFi?
Theorethically you would run into a multi-threading issue, but i thin NT7 is not that much of a multi-threading beast
you would then have to put locks around critical sections
What was the reason to make those things 'static' in the first place ?
Another pattern is to use the singleton, if you really need multiple threads to share the same thing...
Ok, that is what I wanted to know...the potential for collision....I will remove the "static" and instantiate each use....multiple indicators or strategies may want to execute some of these common routines "at the same time", more or less.
Other methods are preferred to be static because they manage global (public) static variables and will only be called by one instance of one class when the workspaces first load.
There is nothing wrong with this. Both processes can access the same piece of code at the same time. The execution code is basically just a location in memory, and both call stacks point to the same location.
It's data where you can run into concurrency issues. For instance, if you are using the singleton pattern you can have different pieces of code modifying the same variables.
I have a custom architecture that when NT boots and the primary workspace opens, one process (running from Market Analyzer) reads a SQL database and loads public static arrays and variables with control/configuration/news data.
Then, later multiple other processes when they are started, read this global data (arrays/variables) and load selected information they need for processing into local process variables.
Sometimes these secondary processes (indicators, strategies), write back status information into the global static arrays/variables to be shared with any process that needs it.
Having the main boot process in the Market Analyzer (against one instrument) was the only way I could figure out in NT to have a boot process load system wide, shared data. It works, but it was not really what I wanted to do.
Yes as I said if two threads are accessing the same variables then you could have problems. This is why singletons become relevant at this point. There are many suggestions about how to write singletons to avoid these kinds of issues. Just search for C# Singletons.
My understanding of a singleton is to have a class that instantiates to the same instance
so that two processes calling the class, are using the same data.
I used it in a trading risk module that is implemented as a DLL and shared by multiple threads
