Programmation d'un processus temporel de longue durée

Question

Je me demandais quelle serait la meilleure façon de rédiger une candidature.Fondamentalement, j'ai un projet de simulation sportive multithread et pouvant exécuter différentes simulations de jeu simultanément.

Je stocke mes correspondances dans une base de données SQLite à laquelle est attaché un DateTime.

Je veux écrire une application qui vérifie toutes les heures environ si de nouveaux matchs doivent être joués et génère ces fils de discussion.

Je ne peux pas compter sur le planificateur de tâches pour exécuter cela toutes les heures, car il existe des objets que les différentes instances de ce processus partageraient (en particulier un objet de tournoi), qui, je suppose, seraient écrasés par un processus plus récent lorsqu'ils seraient réenregistrés dans la base de données. .Donc, idéalement, je dois écrire une sorte de processus de longue durée qui dort entre des heures.

J'ai écrit mon modèle objet de manière à ce que chaque objet ne soit chargé qu'une seule fois depuis la mémoire. Ainsi, tant que tous les threads de simulation sont générés à partir de cette application, ils ne devraient pas écraser les données.

MODIFIER:Plus de détails sur les exigences

Fondamentalement, plusieurs matchs doivent pouvoir s’exécuter simultanément.Ces correspondances peuvent être de longueur arbitraire, il n'est donc pas nécessaire que l'une se termine avant que l'autre ne commence (en fait, dans la plupart des cas, plusieurs correspondances s'exécuteront en même temps).

Ce que j'envisage, c'est un programme qui s'exécute en arrière-plan (un service, je suppose ?) qui dort pendant 60 minutes, puis vérifie la base de données pour voir si des jeux doivent être démarrés.S'il y en a à démarrer, il déclenche des threads pour simuler ces jeux, puis se rendort.Par conséquent, les threads de simulation sont en cours d'exécution mais le thread de « planification » dort pendant encore 60 minutes.

La raison pour laquelle je ne peux pas (je pense) utiliser l'interface de planification des tâches par défaut du système d'exploitation est que celles-ci nécessitent que la tâche à exécuter soit rejetée en tant que nouveau processus.J'ai développé mon modèle objet de base de données de telle sorte qu'ils soient mis en cache par chaque classe d'objets lors du premier chargement (la référence mémoire), ce qui signifie que chaque objet n'est chargé qu'une seule fois depuis la mémoire et que cette référence est utilisée sur toutes les sauvegardes.Cela signifie que lorsque chaque thread de simulation est terminé et enregistre son état, la même référence est utilisée (avec l'état mis à jour) pour enregistrer l'état.Si un exécutable différent est lancé à chaque fois, il est probable qu'une référence mémoire différente sera ouverte par chaque processus et qu'un processus pourrait donc enregistrer dans la base de données et écraser l'état écrit par l'autre processus.

Un service semble être la voie à suivre.Existe-t-il un moyen de faire en sorte qu'un service dorme pendant 60 minutes, puis se réveille et exécute une fonction après cela ?J'ai l'impression qu'en faire une application console standard gaspillerait de la mémoire, mais je ne sais pas s'il existe un moyen efficace de le faire dont je ne suis pas au courant.

Answer 1

Si vous voulez le rendre vraiment fiable, faites-en un service.

Mais je ne vois aucun problème dans la fabrication d'une application normale (console, Winforms, WPF).

Peut-être que vous pourriez accroître les exigences un peu.

Answer 2

La raison pour laquelle je ne peux pas (je pense) utiliser l'interface de planification des tâches par défaut du système d'exploitation est que celles-ci nécessitent que la tâche à exécuter soit rejetée en tant que nouveau processus.J'ai développé mon modèle objet de base de données de telle sorte qu'ils soient mis en cache par chaque classe d'objets lors du premier chargement (la référence mémoire), ce qui signifie que chaque objet n'est chargé qu'une seule fois depuis la mémoire et que cette référence est utilisée sur toutes les sauvegardes.

Si vous souhaitez que tout reste en cache pour toujours, vous devez disposer d'une application qui s'exécute simplement pour toujours.Vous pouvez en faire un service Windows ou une application Windows normale.
Un service Windows n'est qu'un exe normal conforme à l'API du gestionnaire de services.Si vous souhaitez en créer un, Visual Studio dispose d'un assistant qui génère automatiquement du code squelette pour vous.En gros, au lieu d'avoir un Main méthode, vous avez un Service cours avec un Run méthode et tout le reste est pareil.

Vous pouvez, si vous le souhaitez, utiliser le planificateur de tâches Windows pour planifier vos actions.La façon dont vous procéderiez serait d'avoir votre service Windows de longue durée en arrière-plan qui ne fait rien.Demandez-lui d'ouvrir un socket TCP ou un canal nommé ou quelque chose du genre et restez là.Ensuite, écrivez un petit exe "stub" qui se connecte simplement à ce socket ou à ce canal nommé et indique à l'application d'arrière-plan de se réveiller.
C'est bien sûr beaucoup plus difficile que de simplement faire un sleep dans votre application en arrière-plan, mais cela vous permet d'avoir beaucoup plus de contrôle - vous pouvez modifier le temps de veille sans redémarrer le service en arrière-plan, l'exécuter à la demande, etc.

---

Je considérerais cependant votre conception.Le fait que vous dépendiez d’un service de longue durée constitue un point d’échec important.Si votre application doit fonctionner pendant des jours et que vous rencontrez un seul bug qui la fait planter, vous devez alors recommencer.Une bien meilleure architecture consiste à suivre le modèle Unix, dans lequel vous avez de petits processus qui démarrent, font une chose, puis se terminent (dans ce cas, traitez chaque simulation de jeu comme son propre processus, donc si l'un d'entre eux meurt, il ne prend pas le processus principal. ou les autres simulations vers le bas).

Il semble que la principale raison pour laquelle vous essayez de le maintenir à long terme est de mettre en cache vos requêtes de base de données.Avez-vous réellement besoin de faire cela ?La plupart du temps, les bases de données sont assez rapides (elles ont leurs propres caches, qui sont très intelligents).Une erreur courante que j'ai vue faire par les programmeurs est de simplement supposer que quelque chose comme une base de données est lente et de perdre beaucoup de temps à l'optimiser alors qu'en réalité, tout irait bien.