TradeDispatcher: trade context is busy - page 2

 
Thirteen:

Hmm...that is not really what I meant. I was simply attempting to steer the OP away from using Sleep() without adjusting for use in the tester by providing additional information via the links.

There is nothing wrong with using Sleep . . as long as it is used in the way it was intended. It wasn't meant to be used for timing events . . .
 

There is nothing wrong with using Sleep . . as long as it is used in the way it was intended. It wasn't meant to be used for timing events . . .

I agree. There is nothing wrong with using Sleep(); in fact, I use it in the EA that I'm developing. While I can't speak as to its intended use (as I'm still new to MQL and MT4, I don't have the broad range of knowledge of MQL and MT4, so I will defer to those who have such knowledge...maybe one day I'll catch up to ya :) ), I also agree that using Sleep() for timing events, such as waiting for a particular bid/ask prices or some calculation based on bid/ask prices (especially when used in a while loop), creates issues in the tester which may not be present outside of the tester. As I look back to the OP's code, the OP does not appear to be using Sleep() for a timing event, but rather for a mechanism to determine when a particular state has been reached (IsTradeContextBusy() == false). So it appears my original warning regarding the use of Sleep() was unfounded. In this context then, why would there be a need for other mutex routines? Doesn't IsTradeContextBusy() provide an adequate mutex, similar to what the OP was attempting to provide in his/her code?

 

Thirteen:

In this context then, why would there be a need for other mutex routines? Doesn't IsTradeContextBusy() provide an adequate mutex, similar to what the OP was attempting to provide in his/her code?
IsTradeContextBusy() is not a Mutex . . . it is theoretically possible for 2 EAs to both check IsTradeContextBusy() at the same time, both to see it is not busy and to both try to place an order at the same time. The Mutex idea uses a token that can only be used by one EA at a time, the EA with the token can place an Order . . . any others have to wait . . . because they are waiting and not retrying there are no errors to handle, the problem is avoided rather than coped with.
 
Thirteen:
Well, to be honest, I have read the posts (here and here) regarding a mutex, but I don't fully understand them yet (but I will continue to review the concept and the code). Please forgive some of my ignorance; I'm still learning. :)

Simple concept. If you want to use the toilet and someone else is currently sitting on it, you wait outside the door for them to come out.

Remember you need to put the mutex around server calls (send, modify, and close) and RefreshRates() if there was a delay. See my code

 

WHRoeder:

LOL!! Thanks for the analogy. Yes, a simple concept (semaphores and mutual exclusion), but with so many gradations of complexity.

 
Thirteen:

WHRoeder:

LOL!! Thanks for the analogy. Yes, a simple concept (semaphores and mutual exclusion), but with so many gradations of complexity.

Complex ? not really, find WHRoeder's code, read it, figure it out and you will have done yourself a big favour.
Reason: