Asynchronous and multi-threaded programming in MQL - page 19

New comment
 
Igor Makanu:
...


Once again, answer the question: why does the trading terminal need this?

...

Does the terminal work in one thread? If it's in multiple threads, is that why it's needed?))

 
Реter Konow:

There's a lot of reasoning to be done.

Hmm, is that where you go, too? - You write a lot, but you do not read and do not want to develop? - You would not have had time at my link, not only to understand the article, but even read, here's the latest that I found, here's my code on the "3 screens Elder", wrote to someone, I have a code structure is always about that (provided that will not be further modifications that change the basic logic, there code ... better not to remember what can be done to initially linearstructured code (( ) )

void OnTick()
  {
   int takeprofit,stoploss,hstart=0; 
   double lot,h[];
   CopyClose(symbol,PeriodSecondary,hstart,HistoryCount,h);
   ENUM_CMD CMD1,CMD2,CMD3;
   CMD1 = ind1();
   CMD2 = ind2();
   CMD3 = ind3();
   if(NewBar())
     {
      DeleteOrdersLimits(Magic);
      if(CMD1==CMD_BUY && CMD2==CMD_BUY && CMD3==CMD_BUY)
        {
         CalcTakeProfitStopLoss(takeprofit,stoploss);
         lot=CalcLot(stoploss);
         if(ReversSignal)SELL_STOP_PR(Low[1],lot,Magic,stoploss,takeprofit); else BUY_STOP_PR(High[1],lot,Magic,stoploss,takeprofit);
        }
      if(CMD1==CMD_SELL && CMD2==CMD_SELL && CMD3==CMD_SELL)
        {
         CalcTakeProfitStopLoss(takeprofit,stoploss);
         lot=CalcLot(stoploss);
         if(ReversSignal)BUY_STOP_PR(High[1],lot,Magic,stoploss,takeprofit);else SELL_STOP_PR(Low[1],lot,Magic,stoploss,takeprofit);
        }
     }
  }
//+------------------------------------------------------------------+

below will be all the service functions, but the main code - the TC itself as much readable and most linear logic, I always wrote so, at university teachers only such sources accepted as handed in work, otherwise you will not pass ))))


what's the point? - I am trying to say once again: multi-threading should be used only if there is no other solution, no one from the adequate programmers will just go to work with asynchronous operations! - it hurts! ))))


an example will be from you: answer the question why a trading terminal needs it?

 
Yuriy Asaulenko:
Yes, they are in the docks, but in reality they are not. As far as I understood.
Volchansky wrote about this and Renat wrote back to him.
In general, I find it hard to imagine why callbacks are needed in a single-threaded program with no interaction with third-party software.

I have tried it now. Everything is working.

Although they are of no practical use in MQL.

 
Igor Makanu:

Answer the question why does the trading terminal need this?

They've all forgotten about the overhead of multithreading. And they're not insignificant).
 
Igor Makanu:
...


An example would be from you: answer the question why does the trading terminal need it?

I have already answered you. You are ignoring.

1. I need multithreading because my programs are much more complex. I want to combine a lot of heavy functions in one program. Three-dimensional visualization, server communication, GUI, and various calculations. A single thread is not enough. So, I must either split the program into parts or use the native multithreading. If it's not available, then I'll split the program into parts.

2. the terminal is multi-threaded by itself. Ask its developers why it needs multithreading. Why I need multithreading - see point 1.

 

Igor Makanu

example from you: answer the question why the trading terminal needs it?

Well, the most obvious one is a separate interface thread, especially critical for guineas, although I do without it myself.

ZS: I do not advocate multithreading, if anything.

 
Реter Konow:

I have already replied to you. You are ignoring.

1. I need multithreading because my programs are much more complex. I want to combine a lot of very heavy functions in one program. Three-dimensional visualization, server communication, GUI, and various calculations. A single thread is not enough. So, I must either split the program into parts or use the native multithreading. If it's not there, then I'll split the program into parts.

2) The Terminal is multi-threaded in itself. Why it needs multi-threading - ask its developers. Why I need multi-threading - see point 1.

You also ignore what you are told, I've already written: flies separate - cutlets separate!

In your topic about your approach to graphical interfaces, you were told that your code is inefficient and you think that by throwing out functions into a separate thread you will increase performance? - It won't increase performance, but it will create the additional hassle of synchronizing everything now ))))

Remembering on 4pd in the threads about android - devices, the users are convinced of the effectiveness of the firmware version only by the amount of free memory, and quite the opposite - the more free memory, the cooler the firmware, but unfortunately there is no understanding that the OS must efficiently use all the resources - including memory, if there is much free memory, not necessarily the OS uses resources efficiently. So in your case, you can't get performance in one thread, so you need more threads! - Maybe it's not aboutthe capabilities of the language (platform, OS...) but about the developer? - Maybe he isn't efficient? ;) - I checked the GUIs from the article series and in KB last year, I didn't see any obvious lags, everything works at a good level. I looked at the source code of those codes, the interface element traversal schemes, the OOP approaches themselves - all very similar to the principles of graphics in Windows - why does it work for them and not for you? )))))) - Maybe the initial approach was not correct after all, oryour theoretical background is lame on both paws?

 
Igor Makanu:

You also ignore what is written to you, I have already written: flies separate - cutlets separate! GUI and trading strategy should not be executed in one code!

In your topic about your approach to graphical interfaces, you were told that your code is inefficient and you think that by throwing out functions into a separate thread you will increase performance? - It won't increase performance, but it will create the additional hassle of synchronizing everything now ))))

Remembering on 4pd in the threads about android - devices, the users are convinced of the effectiveness of the firmware version only by the amount of free memory, and quite the opposite - the more free memory, the cooler the firmware, but unfortunately there is no understanding that the OS must efficiently use all the resources - including memory, if there is much free memory, not necessarily the OS uses resources efficiently. So in your case, you can't get performance in one thread, so you need more threads! - Maybe it's not about the capabilities of the language(platform, OS...) but about the developer? - Maybe he isn't efficient? ;) - I checked the GUIs from the article series and in KB last year, I didn't see any obvious lags, everything works at a good level. I looked at the source code of those codes, the interface element traversal schemes, the OOP approaches themselves - all very similar to the principles of graphics in Windows - why does it work for them and not for you? )))))) - maybe the initial approach wasn't right after all, or your theoretical background is lame on both paws?

What makes you think that something is inefficient or doesn't work for me? Go to my profile and see how things work. It is precisely because things are working and evolving that I assume the need for multithreading is imminent.

 
Vict:

Well, the most obvious one is a separate interface thread, especially critical for guini, although I do without it myself.

ZS: I'm not advocating multithreading, if anything.

Well, you don't have products in the Marketplace. Then why make a GUI in MKL when it's easily made in C#, which now easily connects to MKL. And that GUI is already inherently running in its own thread.

 
Igor Makanu:

void OnTick()
  {
   MqlTask obj1;
   MqlTask obj2;
   MqlTask obj3;
   MqlTask obj4;

   int takeprofit,stoploss,hstart=0; 
   double lot,h[];

   bool success = false;

   CTask *task1 = obj1.CALLBACK_FUNC(CopyClose(symbol,PeriodSecondary,hstart,HistoryCount,h));   //Выполняется асинхронно в пуле потоков
   success = task1 -> Run();
   success = task1 -> Wait(0);  
   

   ENUM_CMD CMD1,CMD2,CMD3;
   CMD1 = ind1();
   CMD2 = ind2();
   CMD3 = ind3();

   if(NewBar())
     {
      CTask *task2   = obj2.CALLBACK_FUNC(DeleteOrdersLimits(Magic));  //Выполняется асинхронно в пуле потоков
      success = task2 -> Run();
      success = task2 -> Wait(0);

      if(CMD1==CMD_BUY && CMD2==CMD_BUY && CMD3==CMD_BUY)
        {
         CTask *task3 = obj3.CALLBACK_FUNC(CalcTakeProfitStopLoss(takeprofit,stoploss));  //Выполняется асинхронно в пуле потоков
         success = task3 -> Run();
         success = task3 -> Wait(0);

         lot=CalcLot(stoploss);
         if(ReversSignal)SELL_STOP_PR(Low[1],lot,Magic,stoploss,takeprofit); else BUY_STOP_PR(High[1],lot,Magic,stoploss,takeprofit);
        }
      if(CMD1==CMD_SELL && CMD2==CMD_SELL && CMD3==CMD_SELL)
        {
         CTask *task4 = obj4.CALLBACK_FUNC(CalcTakeProfitStopLoss(takeprofit,stoploss));  //Выполняется асинхронно в пуле потоков
         success = task4 -> Run();
         success = task4 -> Wait(0);

         lot=CalcLot(stoploss);
         if(ReversSignal)BUY_STOP_PR(High[1],lot,Magic,stoploss,takeprofit);else SELL_STOP_PR(Low[1],lot,Magic,stoploss,takeprofit);
        }
     }

     delete task1;  //Очищаем ресурсы
     delete task2;
     delete task3;
     delete task4;
  }
//+------------------------------------------------------------------+


Here is an example of writing linear asynchronous code in one thread.
Assuming that the EventLoop functionality is implemented in mql and implemented by the ThreadPool developers.
The user doesn't need to get into the threads! The developers should take care of that and write the corresponding classes.
The program runs in a single thread, while the regular non-blocking collabs are executed in a pool of threads!
Now replace your simple functions in colbacks with functions with heavy calculations or requiring concurrency.
Mega convenient and everything in parallel ))



Files:
node.js.png  48 kb
1...121314151617181920212223242526...40
New comment