MT5 and speed in action - page 74

 
Roman:

Can you elaborate on these objective reasons?

Unreasonable brakes

 
Roman:

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.

 
Slava:

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.

 
Roman:

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.

 
Slava:

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.

 
Roman:

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.

 
Slava:

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

Multi Timer
Multi Timer
  • www.mql5.com
Данная библиотека Вам пригодится, когда Вам необходимы несколько таймеров с независимой обработкой и неконфликтующие между собой. Для работы с данной библиотекой важно запомнить следующие правила: В теле вашей программы не должно быть функции OnTimer , т.к. эта функция уже присутствует в файле Timer.mhq Не надо создавать никаких экземпляров...
 
Roman:

Or what could be the consequences of such an approach?

https://www.mql5.com/ru/code/31306

And what might it be fraught with?
Just in this case, everything is at the mercy of asynchrony and it will take care of everything.
 
Nikolai Semko:
And what could it possibly be worth?
Just in this case, it's all at the mercy of asynchrony and it will sort everything out.

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? ))

 
Roman:

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.