Multithreading + Service

Bonjour,

Je travaille dans l'automatisme et j'ai développé une solution C# sur un ordinateur de gestion d'usine qui communique avec les automates de production:
Un logiciel de gestion de production est installé sur le PC, j'ai développé 3 services distincts.

- A l'aide d'une bibliothèque tierce, j'arrive à accéder aux automates, donc je lis l'occupation (quel contrat) est sur chaque station de travail, et je remplis une table sur SQL Server (installé sur le PC) pour avoir une traçabilité de la production.
- On a un espace de stockage où les produits durcissent (système de plusieurs tours avec des grosses étagères), la durée du durcissement et le temps restant est géré par l'automate, je vais donc toutes les 30 secondes lire le contenu des différentes tours et j'écrase en continue une table avec un nombre de lignes fixes (une ligne par étagère et la table a donc un nombre de ligne fixe et invariant) pour renseigner le contenu de chaque étagère et la durée de durcissement restante. La table est toujours remplie dans la même BDD, un outil de rendu web lis cette table et permet d'afficher l'occupation des tours via un navigateur web.
- Normalement, c'est le logiciel de gestion de production qui envoit les contrats aux automates (il a la même bibliothèque tierce que mes programmes), mais des fois il arrive qu'il y a des ratés, donc l'utilisateur peut rafraichir et recharger un contrat sur une station de travail (via le pupitre de commande, cela met un bit à 1 dans l'automate, mon programme tourne toutes les 10 sec, il regarde si le bit est à 1, si oui quelle station a demandé, puis cherche le contrat associé à la station dans la BDD, écrit le contrat dans les registres automates associés, et reset le bit à 0).

Ces 3 programmes tournent distinctement sur le PC de production, chaque programme a sa propre instance de la bibliothèque de communication avec l'automate.
Chaque programme tourne même en tant que service (avec la même structure, on a un timer et à chaque fois qu'il est écoulé on exécute le programme et ce à l'infini).

On me demande de fusionner ces 3 programmes en un seul (soit disant pour avoir un truc plus facile à gérer et pas avoir 3 modules distincts, moi je pense que ça va apporter que des problèmes en supprimant la modularité).
Je peux très bien mettre les 3 programmes à la suite dans mon timer, mais j'aurai des problèmes d'embouteillage si je mets des temporisation dans chaque sous ensemble (le programme de rechargement s'exécute toutes les 10 secondes, la traçabilité toutes les 30s, le durcissement toutes les minutes...).
Je voudrais donc implémenter ce que fait l'ordonnanceur qui gère les services pour avoir un semblant de multitâche, donc dans mon cas, utiliser les threads.

Sauf que j'y connais rien en threading, et je sais pas non plus comment implémenter ça dans un service.
Pour l'heure chaque programme a la même architecture, une classe statique définissant l'automate (protocole de communication + action de recherche/écriture sur ce dernier), une classe statique définissant la BDD (même logique) et une classe statique qui décrit l'architecture de l'usine (position des stations de travail et adresses automates associées) et appelle les méthodes des classes statiques dans le bon sens pour réaliser le travail, synthétisé dans une classe maitre.

Si vous pouvez me donner des billes pour adapter mon architecture actuelle et des ressources pour le multithreading comme des tutoriaux, ce serait sympa!
Merci.

lu en diagonale

si tu as des timers dans un service et qu'ils fonctionnent ca doit être des threading.timers (ou l'autre qui marche aussià donc y a des chances qu'en mettant 3 timers tu ais déjà 3 threads et que ca marche direct

après garder 3 programmes distinct peut avoir quelques avantages, même si les regrouper aussi :D
le mieux serait peut etre de faire un programme qui ne sait rien faire de spécial, et une dll par truc à gérer
au démarrage du programme il cherche les dll qui sont des "plugins" à côté de lui, et il lance un thread/timer de chaque (on peut rechercher des types dans un assembly qui implémente une interface par exemple)
ca permet de n'avoir qu'un programme donc pas chiant à installer, et de la modularité quand même


concernant le threading, dans le principe quand tu fais du debug pas à pas tu vois ta ligne qui avance
avec un thread supplémentaire tu as l'équivalent d'une autre ligne qui avance, potentiellement au même endroit ou potentiellement ailleurs
et tu peux faire des centaines de threads ^^

en général quand on a un truc à faire timé dans un service on utilise d'ailleurs un thread dédié plutot qu'un timer ...

en vb.net ca donne

Code:

---

1 2 3 4 5

sub onstart() classestatic1.start classestatic2.start classestatic3.start end sub

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

public class classestatic1   public shared sub start() end sub   shared sub new dim th as new thread(addressof traitement) th.Start end sub   private shared sub traitement while true 'mettre un try catch dans la boucle ^^ 'dialogue automate ou autre thread.sleep(x millisecondes) ' équivalent du timer on peut aussi utiliser un chrono pour faire un wait de temps prévu - temps de traitement, peut etre que le timer fait ca par défaut end while end sub   end class

---

ca peut se traduire en c# si nécessaire sur le site de telerik (ou autre)

enfin bref tu peux tenter avec les timers si tu préfères pour voir si les 3 trucs se font bien en même temps ^^

Bonjour,

J'ai écris une série d'articles sur l'utilisation du pool de threads, qui permet de faire assez simplement du multitâche.

Je pense en particulier cet article, sur la réalisation de tâches périodiques, peut donner quelques pistes d'implémentation, et notamment les différences entre l'utilisation de timer et de threads (différences qui ne sautent pas aux yeux, comme le décalage qu'il peut y avoir dans l'exécution de chaque instance d'une tâche).

Merci à vous deux pour vos messages ;)

Très intéressant, autant les idées que les articles, je vais potasser tout ça!