MT5 et trans2quik.dll - page 6
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
Non, j'ai juste besoin de synchroniser 3 threads (en fait, écrire un Synchronizer), mais...
Je ne sais pas comment.
Eh bien, il ne reste que les drapeaux. Nous mettons un drapeau, attendons que les autres terminent leurs activités, s'arrêtent et retirent leurs drapeaux, font des choses, retirent le drapeau. Eh bien, et la logique de la priorité du drapeau, évidemment.
Je n'arrêterais pas le DDE, mais je le laisserais écrire dans le tampon pour que rien ne soit perdu.
Eh bien, il ne reste que les drapeaux. Mettez un drapeau, attendez que les autres terminent leurs activités, arrêtez et descendez leurs drapeaux, faites vos affaires, descendez le drapeau. Eh bien, et la logique de la priorité du drapeau, évidemment.
Je n'arrêterais pas DDE, cependant, je le laisserais écrire dans le tampon pour que rien ne soit perdu.
En d'autres termes, le Synchronizer doit faire un tampon des fonctions entrantes qui seront exécutées en fonction de la priorité ?
Le Synchronizer doit donc mettre en mémoire tampon les fonctions entrantes qui seront exécutées en fonction de leur priorité ?
Non, il suffit de suspendre le(s) fil(s) en fonction des indicateurs pertinents et de leur priorité. Dans cette variante, rien d'autre n'est nécessaire.
La deuxième option consiste à attendre que la fonction du thread se termine, puis à l'arrêter par son drapeau. Cela peut être nécessaire, par exemple, pour mettre à jour l'asc-bid, les indicateurs et tout ce dont nous avons besoin.
Par exemple, les valeurs du drapeau.
0 - le fil est inactif,
1 - le fil est allumé,
2 - demande d'arrêter tous les threads avec une priorité inférieure.
Mettez-le à 2 et attendez que tous les fils deviennent 0, exécutez le programme et mettez-le à 0 ou 1. Grâce à ce drapeau, tous les autres fils reprennent leur travail.
Non, il suffit de suspendre le(s) fil(s) en fonction des indicateurs pertinents et de leur priorité. Cette option ne nécessite rien d'autre.
La deuxième option consiste à attendre que la fonction du thread se termine, puis à l'arrêter par son drapeau. Cela peut être nécessaire, par exemple, pour mettre à jour l'asc-bid, les indicateurs et tout ce dont nous avons besoin.
Par exemple, les valeurs du drapeau.
0 - le fil est inactif,
1 - le fil est allumé,
2 - demande d'arrêter tous les threads avec une priorité inférieure.
Mettez-le à 2 et attendez que tous les fils deviennent 0, exécutez le programme et mettez-le à 0 ou 1. Grâce à ce drapeau, tous les autres fils reprennent leur travail.
Vous avez vous-même écrit qu'il n'est pas bon de suspendre DDE
Vous avez vous-même écrit qu'il n'est pas bon de suspendre une DDE.
Je ne te comprends pas.
Ce que je fais, c'est ça.
Le serveur (j'ai un serveur TCP) dans son fil de discussion écrit constamment des données dans la collection comme le dernier entré premier sorti. Il n'y a pas besoin de l'arrêter.
Les données sont lues/supprimées de la collection dans un autre thread et écrites dans DataTable (c'est l'analogue d'une table de base de données, mais en mémoire). Ce fil peut être mis en pause, s'il est gênant.
3. un autre thread lit les données de DataTable pour les analyser. Ce fil n'interfère pas avec le fil 2 puisqu'il est récupéré par select et que personne d'autre que 2 n'écrit dans cette table. Vous pouvez également arrêter ce fil s'il vous gêne.
Je n'ai pas besoin de mettre en pause quoi que ce soit, car je travaille avec un seul outil et le fil 3 est commuté pour soumettre-exécuter les ordres et suivre les transactions.
Je ne te comprends pas.
Ce que je fais, c'est ça.
Le serveur (j'ai un serveur TCP) dans son fil de discussion écrit constamment des données dans la collection comme le dernier entré premier sorti. Il n'y a pas besoin de l'arrêter.
Les données sont lues/supprimées de la collection dans un autre thread et écrites dans DataTable (c'est l'analogue d'une table de base de données, mais en mémoire). Ce fil de discussion peut être suspendu, s'il est gênant.
3. un autre thread lit les données de DataTable pour les analyser. Ce thread n'interfère pas avec le thread 2 puisqu'il est récupéré par select et que personne d'autre que 2 n'écrit dans cette table. Vous pouvez également arrêter ce fil s'il vous gêne.
Je n'ai pas besoin de mettre quoi que ce soit en pause car je travaille avec un seul outil et le fil 3 est commuté pour soumettre-exécuter les ordres et suivre les transactions.
Tu as de la chance, j'ai 52 outils, donc je dois changer.
Vous avez de la chance, j'ai 52 instruments, donc je dois échanger...
J'en déduis que l'analyse des 52 instruments se fait dans un seul fil ? Ou est-ce le cas ?
Qu'est-ce qui est utilisé comme stockage ? Dans mon cas, avec un accès multi-utilisateurs, le verrouillage est inutile et la lecture n'interfère pas avec l'écriture.
La seule chose qui doit être bloquée est l'accès partagé de l'enfant à trans2quik. Et seulement en cas d'ensemble de fils Enfant. Vous pouvez le faire en organisant trans2quik dans un thread séparé et l'appeler sur un événement et verrouiller simultanément le gestionnaire d'événement jusqu'à ce que la demande soit terminée. Les autres ne peuvent pas l'atteindre).
J'ai complètement abandonné l'idée de lier MT5 et Kvik, je me suis contenté de Kvik (serveur DEE + trans2quik.dll).
Quel dommage. Quelle est la raison de cette décision, y a-t-il des obstacles sérieux à la réception/transmission de données entre les deux programmes ?
J'en déduis que l'analyse des 52 instruments est effectuée en une seule fois ? Ou pas ?
Qu'est-ce qui est utilisé comme stockage ? Dans mon cas, avec un accès multi-utilisateurs, le verrouillage est inutile et la lecture n'interfère pas avec l'écriture.
La seule chose qui doit être bloquée est l'accès partagé de l'enfant à trans2quik. Et seulement en cas d'ensemble de fils Enfant. Vous pouvez le faire en organisant trans2quik dans un thread séparé et l'appeler sur un événement et verrouiller simultanément le gestionnaire d'événement jusqu'à ce que la demande soit terminée. Les autres n'y arriveront pas).
Non, l'analyse elle-même a lieu dans Child (séparément, pour chaque outil) Selector(1,2) choisit le robot auquel envoyer les données et les colbordements.
Stockage - uniquement des tableaux qui sont stockés en mémoire
C'est dommage. Quelle est la raison de cette décision, y a-t-il un obstacle sérieux à la réception/transmission de données entre les deux programmes ?
Ça n'a pas de sens de faire du désordre.
En utilisant MT5, nous avons besoin d'un code dans l'Expert Advisor et d'une DLL, qui recevra les données.
En utilisant uniquement Quick, nous n'avons qu'une seule application (voir la figure avec le diagramme)