Asynchronous and multi-threaded programming in MQL - page 14

 
Реter Konow:

Is it really that dangerous? Errors in memory release...

The example relates to general principles of capturing device context and allocated resources in Windows, when programming independent threads the developer must ensure that the device context and resources are released when required by the OS, if the developer uses low level commands they must release all used resources themselves... here again to the point I wrote - write once using googled information "Hello World"https://www.mql5.com/ru/forum/318593/page5#comment_12572558 and you will understand a lot, you will understand that 99% of the work for you was done by system programmers

I.e. working in MQL environment - the Metakvot programmers did it for you - they made sure that the terminal will work in case the MQL-program does not work properly

 
Andrey Pogoreltsev:

Multithreading - tasks run in multiple threads. Can run on a single processor, still multithreading and switching between them as processor time quotas run out. Requires synchronization for access to shared resources. Can lead to deadlocks, race condition, memory release bugs and other "surprises".

Asynchronous - non-blocked function execution (i.e. control is immediately returned after method exit), usually on other devices (networking equipment, storage devices, peripherals, etc.). For example, it is possible to write a high-performance multi-user server using only one thread and end-machine processing client connections. It all depends on the purpose of this server.

In your case you need to create a large number of connections using WinAPI and you can check the state of those connections with WaitForMultipleObjects with a timeout, so you don't have to hold a timer thread, for example.

PS. Theoretically, you could also use IOCompletionPort, but it requires more knowledge and careful design.

Well... you've found each other.

 
Maybe people don't have enough vitamins or micronutrients...
 
Roman:

Thanks for the informative reply ))
Go ahead and explain what is there and where.
And how to write asynchronous code withEventloop by standard means?

It's all in the documentation.

You can start by reading it and trying to write something.

And if you can't, you can ask on the forum.

So far, we're not talking about anything.


 
Koldun Zloy:

It's all in the documentation.

You can start by reading it and trying to write something.

And if you can't, you can ask on the forum.

So far, we're not talking about anything.


What do you think the topic was created for?
You tell us how to write asynchronous code in the regular way, and show it in the documentation.
Besides asynchronous request sending, show where Callback functions, where controlling EventLoop, where Wait, etc.
I'm sure you won't be able to answer that because there is no such functionality for users, and it's not in the docs.
Exactly the conversation is about nothing, the only person here in the thread isAndrey Pogoreltsev, who understands the topic of communication.

 
Euentloop! Does anyone have a Euentloop? A man's not well here without a Euentloop! Somebody give me a Euentloop!
 

Roman, 2019.07.27 09:30

What do you think the topic was created for?


You asked about multithreading. There isn't any.

But that's not what you need to worry about right now either.

Roman, 2019.07.27 09:30

You tell us how to write asynchronous code using the standard means and show it in the documentation.
Besides asynchronous request sending, show us where Callback functions, where controlling EventLoop, where Wait, etc.
I'm sure you can't give an answer to that because there's no such functionality for users, and it's not in the docs.
Exactly the conversation is about nothing, the only person here in the thread is Andrey Pogoreltsev, who understands the topic of communication.

I can show it all to you. But what's the point?

If you needed it, you would find it yourself.

Obviously you haven't read the documentation or the articles.
 
Koldun Zloy:

You asked about multithreading. There is no multithreading.

The multi-threading is likehttps://www.mql5.com/ru/docs/runtime/running , i.e. we want to parallelize the task, open several graphs (unfortunately I haven't tried to use the Services features yet - maybe it will be even easier with them? ) and attach our EAs working in separate threads to them, then solve the problem of synchronization and data exchange (tasks)

I asked TS five times - why does the trading terminal need it... he does not know, because there is no specific task or purpose

I see it in client-server applications that is not typical for the trading terminal, maybe it is convenient for someone to send statistics to the server? - Well, I have already written a ready example (article)https://www.mql5.com/ru/articles/5337

The sources are readable and the article has excellent quality; the sources can be modified to perform parallel calculations in several threads.... now what should we calculate? )))

 
Igor Makanu:

The example relates to general principles of capturing device context and allocated resources in Windows, when programming independent threads the developer must ensure to release device context and resources when required by OS, if the developer uses low level commands he must release all used resources by himself... here again to the point I wrote - write once using googled information "Hello World" https://www.mql5.com/ru/forum/318593/page5#comment_12572558 and you will understand a lot, you will understand that 99% of the work for you was done by system programmers

In other words, working in MQL environment Metakvot programmers did it for you - they ensured stable operation of the terminal with inadequate work of MQL-programs

OK, no arguments, convinced. Getting the threads right on your own may not be feasible for self-taught coders and can lead to critical errors. "Matches are not toys for children". However, we need some way to achieve multithreading within a single program.

There's a simple logic: sequential launch of services does not cause errors, and each service runs in its thread. So, the mechanism is already configured and debugged. Good. We need to make one step forward: to write these services in the Expert Advisor's code in special modules. Each module will be the same service. Then, we should sequentially compile these modules and run them simultaneously. That's it.

In essence, nothing changes. Only the services will be written inside the owl code. They would compile and work the same way. They will be deleted when the EA is removed from the chart. In this way we obtain a multi-threaded EA.

 
You can make it even simpler. The Expert Advisor loads the required services itself, which are written separately. When removed from the chart, it stops them. The only thing to do is to add the start of services from the Expert Advisor. And the internal interaction between the threads is a task of the programmer. It is solved with the help of resources.