Minuterie - page 2

Nouveau commentaire
 
TheXpert:

Encore une chose... Vous n'êtes pas frères, n'est-ce pas ?

Ce qui ne veut pas dire qu'il n'y en a pas. La mission de chacun est différente.

C'est parti... On peut lire ? Montrez-moi comment on fait pour les induits.


  1. Je ne pense pas, je ne sais même pas qui c'est :D
  2. Honnêtement, je n'ai pas rencontré une telle tâche, pour mes tâches - plus vite ça compte, mieux c'est.
  3. Je suis désolé, je l'ai parcouru)). Je ne suis pas vraiment entré dans les fils de discussion - ce qui se passe. Je ne sais pas, je n'ai jamais vu une telle chose. Cela dépend vraiment de la tâche, à moins que je n'exécute un script bizarre, qui fera tomber l'indicateur.
Ou, comme autre alternative, de pousser tous les calculs et tout ce qui se trouve dans un fil séparé dans une dll - mais cela ressemble à une perversion.
 

Interesting:

... Le traitement de la minuterie ne peut être appelé tant que le traitement de la minuterie précédente n'est pas terminé. Ou plus simplement, OnTimer() n'aura pas le droit de s'exécuter tant que le thread qui devrait traiter le timer n'est pas occupé.

Pour illustrer l'impossibilité de lancer le traitement de la minuterie par le deuxième thread, vous pouvez utiliser cet exemple (bête mais clair) :

int OnInit()
{
//----------------------------------------------------------------------------//
//Work variables
//----------------------------------------------------------------------------//
EventSetTimer(1);
//----------------------------------------------------------------------------//
return(0);
//----------------------------------------------------------------------------//
}

void OnTimer()
{
//----------------------------------------------------------------------------//
//Work variables
//----------------------------------------------------------------------------//
Print(TimeLocal());
Sleep(2000);
//----------------------------------------------------------------------------//
}
Il s'avère donc que les événementsTimer peuvent être ignorés, tout comme les événementsNewTick? Et dans certaines conditions, ils ne peuvent pas être placés dans la file d'attente des événements du conseiller expert ?
 
Yedelkin:
Il s'avère donc que les événementsTimer peuvent être ignorés de la même manière que les événementsNewTick? Et, sous certaines conditions, il peut être exclu de la file d'attente des événements du conseiller expert ?
L'événement NewTick est une exception dans ce cas. Il n'y a pas de chèque pour les autres types d'événements. Si les gestionnaires d'événements s'exécutent plus lentement que la file d'attente des événements ne se remplit, celle-ci débordera et certains événements seront ignorés. Quant à l'exemple ci-dessus, il confirme seulement que l'EA a un seul fil d'exécution et que le traitement des événements est effectué de manière séquentielle, dans l'ordre où les événements sont mis en file d'attente.
Документация по MQL5: Программы MQL5 / События клиентского терминала
Документация по MQL5: Программы MQL5 / События клиентского терминала
  • www.mql5.com
Программы MQL5 / События клиентского терминала - Документация по MQL5
 
antt:
L'événement NewTick est une exception dans ce cas. Il n'y a pas de contrôle pour les autres types d'événements. Si les gestionnaires d'événements sont plus lents que le remplissage de la file d'attente des événements, celle-ci débordera et certains événements seront ignorés. Quant à l'exemple ci-dessus, il confirme seulement que l'EA a un seul fil d'exécution et que le traitement des événements est effectué de manière séquentielle, dans l'ordre où les événements sont mis en file d'attente.

Super, merci pour les explications ! Logique et compréhensible, pas besoin de spéculer.

Intéressant, votre question sur le multithreading des événements est en quelque sorte répondue. Et j'ai même deviné pour OnTimer :)

 
Yedelkin:
Il s'avère donc que les événementsTimer peuvent être ignorés de la même manière que les événementsNewTick? Et dans certaines conditions, ils ne peuvent pas être mis en file d'attente dans les événements de l'Expert Advisor ?

D'après ce que j'ai compris, ça donne quelque chose comme ça :

1. Tous les événements sont placés dans la même file d'attente. S'il existe un événement NewTick dans la file d'attente ou si un tel événement est traité, alors NewTick est ignoré et n'est pas mis en file d'attente.

2. Le programmeur choisit les événements à traiter. Les gestionnaires pour OnTrade, OnTimer et OnTick sont basiques et fréquemment utilisés dans les Expert Advisors.

3. Pendant le traitement d'un événement, les autres ne peuvent pas être traités.

4. si la pile d'événements déborde, les anciens événements sont retirés de la file d'attente sans être traités.

5. Parmi les trois types d'événements ci-dessus, Trade sera généré moins souvent, et NewTick sera généré plus souvent (mais les ticks tels que décrits ci-dessus peuvent ne pas être inclus dans la file d'attente).

6. Le gestionnaire le plus intéressant de ce point de vue est OnChartEvent, qui traite tous les événements du graphique + les événements personnalisés.

Et un grand nombre de ces événements peut facilement faire déborder la file d'attente des événements (dans le cas où il y aurait beaucoup de ces événements).

À mon avis, le seul point positif de cette situation est que les événements OnChartEvent sont générés de manière désordonnée et asynchrone.

Документация по MQL5: Стандартные константы, перечисления и структуры / Константы графиков / Типы событий графика
Документация по MQL5: Стандартные константы, перечисления и структуры / Константы графиков / Типы событий графика
  • www.mql5.com
Стандартные константы, перечисления и структуры / Константы графиков / Типы событий графика - Документация по MQL5
 

Yedelkin:

Intéressant, votre question sur la gestion des événements multithreads semble avoir trouvé une réponse. Et j'ai même deviné pour OnTimer :)

En principe, je n'avais aucun doute quant à l'utilisation d'un thread unique, d'autant plus que le code du conseiller expert lui-même est exécuté dans un seul thread.

Et ce que j'ai décrit est une sorte de rêve sur le futur (disons, sur MT6), quand il y aura du multi-threading dans MT (au moins jusqu'à ce que le flux d'événements ne soit pas séparé pour une raison quelconque).

A l'origine, j'aurais au moins séparé tous les événements ChartEvent dans un thread séparé, mais les développeurs savent mieux que moi...

 

Existe-t-il un moyen de faire en sorte que l'EA génère des événements de type Timer à un moment précis ? Par exemple, au début de la dernière minute de l'heure ou de la journée.

 
Yedelkin:

Existe-t-il un moyen de faire en sorte que l'EA génère des événements de type Timer à un moment précis ? Par exemple, au début de la dernière minute de l'heure ou de la journée.

Bien sûr.
 
TheXpert:
Bien sûr.
À quoi ressemble-t-elle (la méthode), si ce n'est pas un secret ?
 
Yedelkin:
A quoi ressemble-t-elle (la méthode), si ce n'est à un secret ?

Utilisation du gestionnaire de temporisation. Je voulais écrire un article, mais je me suis laissé distraire. Même si cela ne ressemble pas à un article.

Une heure précise ne fonctionnera pas en raison de la nature monofilaire du code et de la file d'attente des événements, mais avec une erreur moyenne inférieure à une seconde (le maximum est limité par le temps d'exécution maximal de l'événement par le code).

De plus, il n'y a qu'une seule minuterie.

Je le fais ?

12345678
Nouveau commentaire