[ARCHIVE]Toute question de débutant, afin de ne pas encombrer le forum. Professionnels, ne passez pas à côté. Je ne peux aller nulle part sans toi - 5. - page 385
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Sergei, quelles sont les questions qui n'ont pas été résolues ? Si c'est le cas :
Par exemple, pour répondre à la question d'Arles, si un EA a comptabilisé des ordres et fait une "sieste" pendant un moment, à ce moment-là, un autre EA qui n'a pas dépassé la limite des fonds alloués (supposons 80% du dépôt - les deux EA auront cette taille) passera un ordre (conclura une transaction sur le marché). Et quand le 1er reprend le travail (et que le terminal de money management a déjà été calculé la veille), il pourra aussi ouvrir une transaction dépassant les limites fixées par le Conseiller Expert ?
Si ce système (hypothétiquement) est multiplié par plusieurs EA, peut-il y en avoir une, où la gestion des risques sera dans un système critique ?
Est-ce que je comprends bien ce multithreading ? - Si c'est le cas, alors d'un point de vue financier, bien sûr, c'est un gâchis. Mais comme la probabilité est faible pour les petits comptes, ce n'est qu'hypothétique. Et pour les comptes plus importants, ils écriront probablement eux-mêmes quelque chose. Mais quand même, est-ce que cela s'avère être le cas ?
Et j'ai une question : est-ce la position officielle ou s'agit-il seulement de spéculations et d'expériences comme les miennes ?Il y a un code à la page 378. C'est reparti :
Lorsque le délai est "travail d'imitation", insérez une référence au dépôt ou à une autre ressource.Vous pouvez transformer ce bloc de synchronisation en fonction et le placer dans la bibliothèque. Vous disposerez d'une fonction synchrone d'accès au dépôt depuis n'importe quel EA.
Au lieu de l'index, remplacez le handle de la fenêtre du graphique par le handle de la fenêtre du graphique.
C'est ça ! Il est difficile de faire la part des choses avec les indices.
Je l'ai refaite.
===================
Cependant, l'indexation permettra de supprimer correctement une variable globale.
Nous devrions décrémenter l'index dans le deinit. Et supprimer la variable globale lorsque l'indice est égal à zéro.
Mais cette décrémentation ne permettra pas de recharger le script après sa suppression. Les indices seront mélangés.
Nous devons créer un tableau global d'indices de tous les modules qui accèdent à la ressource. Eh bien, et travailler avec.
Il est également possible de créer deux variables globales. L'un avec le dernier indice, l'autre avec le nombre actuel de modules. Les indices ne font qu'augmenter. Probablement, ce sera plus facile.
Ou bien ne pas s'embêter avec les variables globales du tout. Supprimez-la manuellement avant la première exécution.
1) Problème : chaque script (EA) doit être conscient de la présence de tous les autres.
2) Problème : s'il y a un échec, les globaux de celui qui a échoué resteront inoccupés et la file d'attente sera bloquée.
3) Solution :
Chaque exp organise 1 globalka avec le nom - préfixe commun + poignée de fenêtre + symbole. La valeur du globalka est le temps du dernier tick sur cet instrument. 2 global commun avec sa propre poignée (après avoir travaillé, il écrit sa propre poignée dans celui-ci ou l'efface s'il est le plus ancien)
La file d'attente est classée par ordre croissant (poignées), la plus ancienne met la deuxième globale à zéro.
dans chaque exp, nous créons trois tableaux (par manque de structures) - symbole/manipulateur/dernier temps d'accès/dernier temps de tic.
tous les EXPs gardent la trace de (last access time/last tick time) pour chacun d'entre eux et dès qu'ils sont différents (un des EXPs tombe en panne) les deux globaux de l'EXP en panne sont supprimés et il est considéré comme inactif. ses cellules dans les tableaux sont supprimées (le tableau est reconstruit).
la file d'attente est restaurée
cette opération sera en fait effectuée par l'EA se trouvant sur le graphique le plus actif (ticks fréquents).
lorsqu'elle est désinitialisée normalement, chaque expo nettoie après elle-même.
saut max - une coche.
ZS. et en général, il est préférable de faire une seule multidevise
Sergei, quelles sont les questions qui n'ont pas été résolues ? Si c'est le cas :
Il y a un code à la page 378. C'est reparti :
Lorsqu'il y a un délai "imitation d'œuvre", vous insérez une référence au dépôt ou à une autre ressource.Vous pouvez transformer ce bloc de synchronisation en fonction et le placer dans une bibliothèque. Vous obtiendrez une fonction synchrone d'accès au dépôt à partir de n'importe quel conseiller expert.
Il s'agit d'un bloc d'accès atomique et il n'y a pas de synchronisation. Cela n'a aucun sens de ne s'appliquer qu'au dépôt. L'appel de l'une des fonctions des paramètres de dépôt sera atomique par lui-même, sans aucun coup de pouce. Si vous le faites de manière atomique, tout le travail du conseiller expert. C'est ainsi que l'on résout les problèmes - on pense avoir fait quelque chose, mais en fait c'est une illusion.
1) Problème : chaque script (EA) doit être conscient de la présence de tous les autres.
2) Problème : s'il y a un échec, les globaux de celui qui a échoué resteront inoccupés et la file d'attente sera bloquée.
3) Solution :
Chaque exp organise 1 globalka avec le nom - préfixe commun + poignée de fenêtre + symbole. La valeur du globalka est le temps du dernier tick sur cet instrument. 2 global commun avec sa propre poignée (après avoir travaillé, il écrit sa propre poignée dans celui-ci ou l'efface s'il est le plus ancien)
La file d'attente est classée par ordre croissant (poignées), la plus ancienne met la deuxième globale à zéro.
dans chaque exp, nous créons trois tableaux (par manque de structures) - symbole/manipulateur/dernier temps d'accès/dernier temps de tic.
tous les EXPs gardent la trace de (last access time/last tick time) pour chacun d'entre eux et dès qu'ils sont différents (un des EXPs tombe en panne) les deux globaux de l'EXP en panne sont supprimés et il est considéré comme inactif. ses cellules dans les tableaux sont supprimées (le tableau est reconstruit).
la file d'attente est restaurée
cette opération sera en fait effectuée par l'EA se trouvant sur le graphique le plus actif (ticks fréquents).
lorsqu'elle est désinitialisée normalement, chaque expo nettoie après elle-même.
saut max - une coche.
ZS. et en général, il est préférable de faire une seule multidevise
Il ne comprendra pas, trop mal vu d'en haut)))). J'ai résolu cette tâche à peu près dans ce style. C'est agréable d'avoir quelqu'un qui comprend l'essence du problème. Seulement j'ai encore une file d'attente, dans laquelle les tâches ont commencé à être exécutées, et sont exécutées plus loin en cercle.
Il ne comprendra pas))) J'ai résolu ce problème à peu près dans ce style. C'est agréable d'avoir quelqu'un qui comprend l'essence de la tâche. Seulement, j'ai toujours une file d'attente, dans laquelle les tâches ont commencé à être exécutées, et dans laquelle elles sont exécutées plus loin dans un cercle.
Bien, alors au lieu des expansions, les exps eux-mêmes sont définis avec un index, alors la file d'attente sera au moment de la première exécution.