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
Can you elaborate on these objective reasons?
Unreasonable brakes
If people here don't understand what's being written about, I'm sorry, it's not my problem, it's the problem of those who don't smoke the topic of conversation.
No. It's your problem. You're the one who brought it up without understanding the point and the implications.
It has been discussed many times here over more than 10 years.
Unreasonable slowdowns
So a task manager running in an event loop, scattering multiple tasks (equal to the number of handlers) will cause slowdowns?
After all, there aren't that many handlers, just a few. They just need to be scattered among tasks and released to their own event loop.
At the same time, control the handler's execution flag. The handler worked, reset the flag, and so on.
Somehow, I don't believe in slowdowns, we don't handle all of the events, but only the equal number of handlers.
And the handlers themselves have their own events.
So a task manager running in an event loop, scattering multiple tasks (equal to the number of handlers) will cause slowdowns?
There aren't that many handlers, just a few. They just need to be scattered among tasks and released to their own event loop.
At the same time, control the handler's execution flag. Execute the handler, reset the flag, and so on.
It will not come back to the brakes, it is not all events are handled, but only the equal number of handlers.
The handlers have their own events.
Where there is a writer, the reader has to wait. Until the writer writes.
If there is more than one reader, it must negotiate its own variables. While one incarnation changes the contents of the variable, the others wait. Even if there are no other incarnations at the moment, locking the resource still goes to the system core, an expensive operation. The fun begins when all incarnations go after the trading environment. God forbid they start trading at the same time.
All in all, young people don't listen to what they are told. Repeatedly. With examples. With explanations. For more than ten years in a row.
No. This is your problem. You are the one who brought it up without understanding the point and the consequences.
It has been discussed many times here over more than 10 years.
All I have seen from opponents is inadequate attacks rather than constructive discussion.
If you had intervened in a timely manner to clarify the matter, there would have been no unnecessary questions.
And when a developer keeps silent, you do not know what to think. A lot has changed in the world of technology in 10 years.
Okay, now I understand that you heard me, I hope you will think again about this issue. Maybe you can solve it, that would be really cool.
I have only seen inadequate attacks from my opponents, not constructive discussion.
If you had intervened in a timely manner with clarification, there would have been no unnecessary questions.
And when a developer keeps silent, you do not know what to think. A lot has changed in the world of technology in 10 years.
Okay, now I understand that you heard me, I hope you will think again about this issue. Might be able to work it out, would really be cool.
The inadequate attacks are, "shh, again?"
All the answers were normal. The attacks were just from me. I'm sorry if I offended you.
And the guys responded appropriately enough.
Where there is a writer, the reader has to wait. Until the writer writes.
If there is more than one reader, the reader must negotiate his or her own variables.
While one incarnation changes the contents of the variable, the others wait.
Even if there are no other incarnations at the moment, locking the resource still goes to the system core, an expensive operation.
The fun begins when all incarnations go after the trading environment. God forbid they start trading at the same time.
All in all, young people don't listen to what they are told. Repeatedly. With examples. With explanations. For more than 10 years in a row.
As I understand from the above, the problem is the writer/reader synchronicity itself, which can be expensive.
No sync, no problem. Hmmm, succinctly wise, on the optimization side. Thanks for the clarification Uncle Slav ))
Please don't hold it against me either. I'm not a magician, I'm just learning ))
I just don't understand, in real-time systems, everything works in multitasking mode, and synchronization procedure is the main tool.
So, OSRT is a braking system too? Doesn't seem logical. Although, there are also deadlines, latency and jitter.
And what can you say about the object model, there is a race here? Or what can be the consequences of such an approach?
https://www.mql5.com/ru/code/31306
Or what could be the consequences of such an approach?
https://www.mql5.com/ru/code/31306
And what could it possibly be worth?
Hello Nikolai. Well, it's true.
But won't it cause the same problem as with synchronization that Slava talks about, i.e. unreasonable braking.
Or maybe there is no problem? )) Maybe it is easier not to use asynchronous model than to synchronize it with priorities? ))
Hello Nikolai. That's true.
But won't there be the same problem as with synchronisation, which Slava talks about, i.e. unreasonable brakes.
Or maybe there is no problem? )) Maybe it is easier not to use asynchronous model than to synchronize it with priorities? ))
I'm not an expert. in graphs. The importance is determined by the dependence of the start of other tasks on the end of the current one. other criteria are secondary. but there is also the execution time of the task. and it is also the most important among peer-to-peer. In general it is difficult and most sad, it is impossible to change a prioritised algorithm on the fly. On the good side, I would like some clarification from the developers before any questions arise. It is difficult, but it is the right goal in the development of the environment.