Diskussion zum Artikel "Die eigene, multi-threaded, asynchrone Web-Anfrage in MQL5"

 

Neuer Artikel Die eigene, multi-threaded, asynchrone Web-Anfrage in MQL5 :

Der Artikel beschreibt die Bibliothek, mit der Sie die Effizienz von HTTP-Anfragen mit WebRequest in MQL5 erhöhen können. Die Ausführung von WebRequest im nicht-blockierenden Modus verwendet in zusätzliche Threads, die Hilfscharts und Expert Advisors verwendet, um nutzerdefinierte Ereignisse austauschen und gemeinsame Ressourcen lesen. Die Quellcodes sind ebenfalls besprochen und beigefügt.

Die Umsetzung von Handelsalgorithmen erfordert oft die Analyse von Daten aus verschiedenen externen Quellen, einschließlich des Internets. MQL5 stellt die Funktion WebRequest zum Senden von HTTP-Anfragen an die "Außenwelt" zur Verfügung, die hat aber leider einen spürbaren Nachteil. Die Funktion ist synchron, d.h. sie blockiert den EA-Vorgang für die gesamte Dauer einer Auftragsausführung. MetaTrader 5 weist jedem EA einen einzelnen Thread zu, der sequentiell die vorhandenen API-Funktionsaufrufe im Code ausführt, sowie eingehende Event-Handler (wie Ticks, Tiefe der Marktveränderungen in BookEvent, Timer, Handelsoperationen, Chart-Events, etc.). Es wird jeweils nur ein Codefragment ausgeführt, während alle verbleibenden "Tasks" in Warteschlangen warten, bis sie 'drankommen' und bis das aktuelle Fragment die Kontrolle an den Kernel zurückgibt.

Wenn ein EA beispielsweise neue Ticks in Echtzeit verarbeitet und regelmäßig Wirtschaftsnachrichten auf einer oder mehreren Websites überprüft, ist es unmöglich, beide Anforderungen zu erfüllen, ohne dass sie sich gegenseitig stören. Sobald WebRequest im Code ausgeführt wird, bleibt die EA auf der Funktionsaufrufzeichenkette "eingefroren", während neue Tick-Ereignisse übersprungen werden. Selbst mit der Möglichkeit, übersprungene Ticks mit der CopyTicks-Funktion zu lesen, kann der Moment für eine Handelsentscheidung verpasst werden. So zeigt sich diese Situation, veranschaulicht durch ein UML-Ablaufdiagramm:

Ablaufdiagramm der Ereignisbehandlung mit der Blockierung bei nur einem Thread

Abb. 1. Ablaufdiagramm der Ereignisbehandlung mit der Blockierung bei nur einem Thread

Autor: Stanislav Korotky

Grund der Beschwerde: