Errors, bugs, questions - page 2780
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Steps to play:
It's impossible not to say Thank you for a job like this! Hopefully on other bugs we'll get something similar someday.
Don't cry, it's been a long time since I answered:
Unfortunately, the output turned out to be not just zero, but negative...
Well, why negative...
I didn't get it the first time, I didn't get it the second time, but I got it the third time.
I can't help it if I'm so thick. It's not your fault.
So, don't be offended, Sergei.
You have some misunderstanding of the terms asynchronous and synchronous.
When you say that a function is asynchronous, it means that it will be executed not in the current thread of execution, but in some other thread.
Calling an asynchronous as ChartSetInteger function from the main thread is fast as the actual execution occurs in a different thread.
On the other hand, a call of a ChartGetInteger synchronous function will require synchronization of threads and this may require additional time.
The delays are especially noticeable when the parallel thread is constantly updating the chart structure data (for example, when the user moves the chart window or scrolls through the history).
Most likely, for simplicity and reliability, a single synchronization object is used for its chart data structure.
You can try to improve the speed of execution using "data segmentation", but on the other hand now you can run into deadlocks, or under-updated data, or slowdowns in other more critical areas.
In general, it's better not to touch something that is already running stably.
No. Get methods are synchronous, but they can be grouped and executed simultaneously, so the call to method 1 Get or 100 is almost identical.
Set methods are asynchronous, but they can also be grouped for greater efficiency.
Thus it is always better to group 'Set calls together' and 'Get calls together' rather than 'Get / set / get / set / get / set'.
Asynchronous calls are more efficient if the calling thread is not blocked while the function is running, but you will lose these benefits if you mix Get and Set.
I hope this helps, despite the translation.
As I understand it - Get is synchronous, as they return the requested result. But if you have asynchronous Set in the queue, you have to sync with them.
If there are only Get's in the queue, there is no delay.
Thank you all. I am slowly starting to get the hang of it.
Now the true picture of such delays becomes clear.
As I understand it (correct me, please, if I'm wrong):
When the Get method is called from the main thread, there is a request to the chart thread itself, which runs parallel to the main thread. But the main thread is controlled directly from the main thread by Set methods and the main thread should already know the current state of the chart thread, but it just doesn't know the current state of the chart thread and isn't sure if the last commands have been executed. That's why this request happens, to make sure that all previous commands are executed. Since the Get method is synchronous, it waits until a response is received from the parallel chart thread. This is the reason for delays.
If I have not made a mistake, a question occurs:
Why can't the main thread report to the thread that its command is executed, so that the main thread can mark the command as executed and update its internal chart table? Then the main thread would return the data from the table without making requests to the main thread. In addition, you could pass a flag saying that there are commands which are not yet executed to the parallel thread or all commands have been executed to understand the current state of the chart. There won't be any delays with this scheme.
I have implemented approximately a similar mechanism in iCanvas class.
Here's an indicator, demonstrating this mechanism, where there is an incredibly slow function ChartXYToTimePrice to associate pixel coordinates with chart time and price and create its analog, the XYToTimePrice function, which updates its internal static variables at CHARTEVENT_CHART_CHANGE event and calculates the requested parameters based on data from this static chart of chart parameters.
Thank you all. I'm slowly starting to get the hang of it.
...This is true. And, as Renat said, the cache system needs to be implemented on the mql side. Perhaps it could be implemented on the platform side, but that would compromise the achievement of the most productive possible multithreaded architecture.
I see.
All the better for those who understand how to implement this cache system, and worse for those who don't.
I'll try to use an analogy, if it doesn't work out that way, then so be it.
It's all very exaggerated and not true, but still.
There is you, the customer, who determines and brings the paints to the artist, and there is the artist, who uses the paints you bring and paints with them on the canvas.
After you bring the paints, you are free to go about your business: work, home, school, .....
You can also visit the painter at any time and inspect the result.
However, if you come for an inspection and the artist is painting, you will have to wait until the artist finishes his work.
The best way of interaction is to bring the painter all the paints he needs, order him to paint and then go about your business.
At the end, if necessary, you can visit the painter for inspections as many times as necessary to access the canvases.
The most sub-optimal way to interact is to bring the painter one paint at a time and then demand the result right away, waiting for the painter to complete his work each time.
What's the problem in 2485 compared to the 2009 build:
Artist moved closer to you, the travel time for the inspection began to spend less, which is a plus.
However, the artist has started spending a lot of time on "part-time" work on the side.
He used to take "part-time jobs" with the same frequency, but now you have to wait too long for the artist to complete the work.
I see.
All the better for those who understand how to implement this cache system, and worse for those who don't.
The best way to interact is to bring the painter all the paints you need, order him to paint, and then go about your business.
At the end, if necessary, you can visit the painter for an inspection as many times as you want - you will have free access to the canvas.
In my opinion the best way is to agree with the artist that as soon as he finishes a painting he will state a particular completed work on his site that is available for viewing and also agree that he would indicate his current status - whether he is doing part-time work or free.
Then you will know which picture is ready and which is not without visiting the artist and if the artist is busy or free at the moment, you can send him the next job. And there will be no need to travel in vain with an inspection. It will save time and nerves for both the client and the artist.
1) In my mind, the best way is to agree with the artist,
2) as soon as he finishes some regular painting,
3) then he immediately pointed to a specific work done on their site, which is available for viewing by the customer,
4) as well as agree to specify on the site of its current status - it is busy moonlighting or free.
5) Then the client will know .... If the artist is currently busy or free and you can send him the next job.
6) And there will be no need to travel in vain with the inspection. It will save time and nerves for both the client and the artist.
1) The artist doesn't know your plans and you don't know the future either...
2) There are no paintings, there is one canvas on which all the manipulation and "tinkering" goes.
3) To introduce processes unrelated to the source material into an analogy is not to understand what an analogy is and what it is for.
4) A painter does not know the future and if you need to come for an inspection, his status may change a hundred times during the journey.
5) You can bring paint in at any time, it always takes the same amount of time regardless of the status of the artist or their employment.
6) Again not understanding the essence of what an analogy is and what it is for...