Can ClientTerminal [for whatever reason] having called prog.1 change context to prog.2 even if prog.1 not return() ?
But, I am curious about the atomic nature of GV's especially IF Terminal can move to prog.2 without prog.1 having finished/return() from start().
Should a GV counter be guarded by another Semaphore GV?
As I read it, GlobalVariableSetOnCondition() will be atomic/undivisable and acquiring a GV.sem if available, will be done firstly before the context switch IF Terminal can do this.
Each EA runs as a separate thread. Of course the terminal can run the second EA without the first returning. Otherwise there would be NO NEED for a semaphore. Also EAs never have to return from start and can still be functional.
Should a GV be guarded by a semaphore? Depends on what the GV is being used for. Only the programmer can answer that question.
If use SetOnCondition in my semaphore. I assume that it is atomic. That has nothing to do with context switches.
Thank you for info on terminal behaviour and semaphore information.
You hit the nail squarely, GV usage and sem requirement is indeed my responsibility..
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
confused am I:
I ask due to Global Variables. This article Synchronization of Expert Advisors, Scripts and Indicators was very helpful regards multi EA instances and the money management implications.
But, I am curious about the atomic nature of GV's especially IF Terminal can move to prog.2 without prog.1 having finished/return() from start().
Should a GV counter be guarded by another Semaphore GV?
As I read it, GlobalVariableSetOnCondition() will be atomic/undivisable and acquiring a GV.sem if available, will be done firstly before the context switch IF Terminal can do this.
I invisaged doing: eg, acquire sem using GlobalVariableSetOnCondition(sem,1,0) > update GV using GlobalVariableGet(sem) and GlobalVariableSet(sem,updateValue) > release sem using GlobalVariableSet(sem,0)
But this is overkill if just doing a ..Get GV > update the value > ..Set GV will be good enough.
So, what gets me is the possibility of Terminal interuption such that another instance or other program can read GV and react to the value which should have been updated prior to it's access.
This possible interuption seems to impact on prog.1 calcuating risk with accounting Terminal functions and before it finishes or indeed before it makes a trade, it gets pre-empted - which seems to me that its calculations are now voided if prog.2 manages to do its risk calcs and send a trade. Here a semaphore would stop others from atempting to do any accounts calcs/send trade. Sem would act like higher level IsTradeAllowed() mechanism Terminal has..
Help....!