[C#] DLL multithread

Bonjour,
Je dois programmer une DLL qui va recevoir des requêtes d'un programme externe, les mettre dans une collection, et ensuite traiter les requêtes.
J'aimerais qu'un thread s'occupe de recevoir les requêtes du programme, et les mette dans la collection, et qu'un autre thread s'occupe de traiter les requêtes.
Ma question est : est-ce qu'un seul thread peut s'occuper de recevoir les requêtes et les mettre dans la collection, ou faut-il créer un nouveau thread à chaque requête ? Les 2 sont-ils réalisables et y aurait-il une possibilité meilleure que l'autre ? Il se peut que plusieurs requêtes arrivent en même temps.
Merci d'avance pour vos réponses.

Bonjour,

Tu peux créer un thread qui va recevoir les requêtes.
Ce thread quand il en reçoit une déclenche un nouveau thread qui va placer dans une collection. Et enfin un dernier thread qui exécute les requêtes de la collection

Citation:

---

Envoyé par LaChips

Bonjour,

Tu peux créer un thread qui va recevoir les requêtes.
Ce thread quand il en reçoit une déclenche un nouveau thread qui va placer dans une collection. Et enfin un dernier thread qui exécute les requêtes de la collection

---

Bonsoir,
Merci pour ta réponse rapide.
Je vois ce que tu veux dire. Mais comment dois-je programmer le "thread qui va recevoir les requêtes" ? L'invocation de la DLL doit-elle se produire par appel de fonction qui va informer le thread ?

En fait cela dépend de comment est architecturé ton application qui utilisera la DLL

Citation:

---

Envoyé par LaChips

En fait cela dépend de comment est architecturé ton application qui utilisera la DLL

---

Mon application qui utilise la DLL appelle une fonction définie dans la DLL. Je ne vois pas ce que tu veux dire par comment elle est architecturée ?

Bonjour,

Où sera hébergée la DLL ? (une DLL par définition n'est pas exécutable directement)
Quel est le protocole utilisé pour la communication entre le programme externe et la "DLL" ?
Quelle est l'implémentation de la collection choisie ? Certaines implémentations peuvent effectivement avoir des fonctions d'ajout dans certains cas de complexité O(n+1) où n est le nombre de requêtes en attente.

Citation:

---

Envoyé par Kaidan

Bonjour,

Où sera hébergée la DLL ? (une DLL par définition n'est pas exécutable directement)
Quel est le protocole utilisé pour la communication entre le programme externe et la "DLL" ?
Quelle est l'implémentation de la collection choisie ? Certaines implémentations peuvent effectivement avoir des fonctions d'ajout dans certains cas de complexité O(n+1) où n est le nombre de requêtes en attente.

---

La DLL sera hébergée dans un projet visual studio 2005 avec l'application qui n'est qu'une interface graphique de test pour l'instant.
Le programme externe invoque la DLL avec un simple appel de fonction.
La collection est une ArrayList.

Merci d'avance.

Bonjour,

J'ai du mal à voir où est le programme "externe". En fait, ton programme utilise une DLL que tu as écrites et qui est donc réutilisable par d'autres applications. Il n'empêche que ton application charge la DLL dans son appdomain et que par conséquent il n'est pas un programme "externe" pour les fonctions de la DLL.

ArrayList est une très mauvaise implémentation de collection pour effectuer une queue de requêtes à mon avis. De plus, il faudrait lui préférer son équivalent générique List.

Citation:

---

Envoyé par Kaidan

ArrayList est une très mauvaise implémentation de collection pour effectuer une queue de requêtes à mon avis. De plus, il faudrait lui préférer son équivalent générique List.

---

Certes, mais si c'est pour implémenter une file, autant utiliser l'objet adéquat : Queue.

Citation:

---

Envoyé par SaumonAgile

Certes, mais si c'est pour implémenter une file, autant utiliser l'objet adéquat : Queue.

---

OK

Citation:

---

Envoyé par Kaidan

Bonjour,

J'ai du mal à voir où est le programme "externe". En fait, ton programme utilise une DLL que tu as écrites et qui est donc réutilisable par d'autres applications. Il n'empêche que ton application charge la DLL dans son appdomain et que par conséquent il n'est pas un programme "externe" pour les fonctions de la DLL.

---

Mon application n'est pas un programme externe mais ma DLL doit effectivement être réutilisable par d'autres applications.
Je repose donc ma question : comment réaliser l'appel de la DLL sachant qu'un thread va recevoir les requêtes de l'extérieur ?

L'appel à l'assembly ne change pas, c'est à la méthode appelée de créer un thread pour traiter les données. Pour l'application externe ce thread sera invisible.

Citation:

---

Envoyé par SaumonAgile

L'appel à l'assembly ne change pas, c'est à la méthode appelée de créer un thread pour traiter les données. Pour l'application externe ce thread sera invisible.

---

OK. Pensez-vous que cela puisse fonctionner sans thread ? c'est-à-dire que la fonction appelée mette la requête dans une Queue pendant que le programme principal traite les requêtes qui sont dans la Queue.

Pour effectuer les traitements en parallèle, il faut passer par des threads.

Citation:

---

Envoyé par SaumonAgile

Pour effectuer les traitements en parallèle, il faut passer par des threads.

---

Je me demande si ca serait pas intéressant d'utiliser un threadpool, car ma DLL va agir en tant que serveur. J'hésite entre des threads "normaux" et un threadpool. Qu'en pensez-vous ?

Le threadpool est une bonne solution, ça t'épargne une partie du travail. Mais garde à l'esprit que même si tu gères les threads à la main, ils proviennent du même threadpool que ceux gérés par le framework.

OK. Je vais essayer avec un threadpool.
Merci à tous pour vos réponses. :)

Bonjour,
Je pense donc programmer ma DLL "serveur" en utilisant un pool de threads.
Ensuite les requêtes doivent être envoyées à un automate programmable, pour l'instant une seule à la fois, et ensuite il pourrait y avoir plusieurs communications simultanées avec les automates.
Est-ce que j'aurai encore besoin d'une queue qui va stocker les requêtes, ou le pool de thread va-t-il s'occuper de cela ?
Merci d'avance pour votre avis.

Ca dépends encore une fois de ton architecture.

Si tu veux intercepter plusieurs requêtes en même temps et les dispatcher directement vers ton automate (qui va donc dans certains cas devoir gérer plusieurs requêtes en même temps) utilise directement ThreadPool.QueueUserWorkItem pour placer chaque exécution de requête en fille d'attente.

Si tu veux intercepter plusieurs requêtes en même temps mais dispatcher dans ton automate une à une, il va falloir utiliser une Queue entre le ThreadPool et le thread chargé d'envoyer dans l'automate.

Citation:

---

Envoyé par Kaidan

Si tu veux intercepter plusieurs requêtes en même temps mais dispatcher dans ton automate une à une, il va falloir utiliser une Queue entre le ThreadPool et le thread chargé d'envoyer dans l'automate.

---

Voici la solution que je retiens.
Pensez-vous qu'il faut un thread supplémentaire pour déclencher les threads du pool, ou la fonction déclenchée lors de l'appel de la DLL peut-elle se charger de déclencher les threads du threadpool ?

Autre question : J'ai lu que le threadspool du .NET Framework ne gère que 25 threads. Que se passe-t-il si par exemple 30 requêtes arrivent en même temps ?

Merci d'avance.

Par défaut, le ThreadPool gère effectivement 25 threads par processeur d'où l'interêt de QueueUserWorkItem : 25 requêtes par processeur seront traitées directement par un thread du pool et les suivantes seront mise dans la liste d'attente jusqu'à ce qu'un thread se libère.

L'automate, c'est une fonction du programme ou un programme à part ?
Comment le programme qui reçoit les requêtes communique avec l'automate ?

Citation:

---

Envoyé par Kaidan

Par défaut, le ThreadPool gère effectivement 25 threads par processeur d'où l'interêt de QueueUserWorkItem : 25 requêtes par processeur seront traitées directement par un thread du pool et les suivantes seront mise dans la liste d'attente jusqu'à ce qu'un thread se libère.

L'automate, c'est une fonction du programme ou un programme à part ?
Comment le programme qui reçoit les requêtes communique avec l'automate ?

---

Je pense que je vais utiliser les 2, QueueUserWorkItem et une Queue.
L'automate est un automate programmable industriel avec lequel la DLL va communiquer en utilisant un port série.

Penses-tu qu'il faut un thread supplémentaire pour déclencher les threads du pool, ou la fonction déclenchée lors de l'appel de la DLL peut-elle se charger de déclencher les threads du threadpool ?

Si l'hôte de la DLL ne fait QUE réceptionner les requêtes et les mettre dans le ThreadPool pour ajout dans la queue de requêtes, autant utiliser le thread de l'application. Si il fait d'autres choses (gérer Start / Stop), interagir avec la Console etc. mieux vaut utiliser un autre thread.

Citation:

---

Envoyé par Kaidan

Si l'hôte de la DLL ne fait QUE réceptionner les requêtes et les mettre dans le ThreadPool pour ajout dans la queue de requêtes, autant utiliser le thread de l'application. Si il fait d'autres choses (gérer Start / Stop), interagir avec la Console etc. mieux vaut utiliser un autre thread.

---

Le Thread chargé de prendre les requêtes dans la Queue et les envoyer à l'automate fonctionnera en permanence, donc je pense que ce sera le thread de l'application.
Le thread réceptionnant les requêtes et les placant dans la queue ne ferait que ca, s'il en faut un.
Qu'en penses-tu ?

A mon avis, le mieux est de conserver le thread principal pour pouvoir le killer au besoin et envoyer un message à tous les autres threads pour dire "on arrête d'écouter, on envoie tout et on ferme" histoire de quitter proprement. Lors de l'intialisation du programme, tu peux créer le thread qui se charge d'accepter les requêtes entrantes et le thread qui se charge de poller la queue de d'envoyer à l'automate.

Citation:

---

Envoyé par Kaidan

A mon avis, le mieux est de conserver le thread principal pour pouvoir le killer au besoin et envoyer un message à tous les autres threads pour dire "on arrête d'écouter, on envoie tout et on ferme" histoire de quitter proprement. Lors de l'intialisation du programme, tu peux créer le thread qui se charge d'accepter les requêtes entrantes et le thread qui se charge de poller la queue de d'envoyer à l'automate.

---

Je pense que tu as raison. Le thread principal crée tous les autres threads et les termine lorsqu'il faut arrêter tout.
Je vais essayer comme ca.

Bonjour,
J'ai une question au sujet de ma DLL.
Cette DLL contient un fichier program.cs, ce fichier contient une fonction Main. Quelqu'un sait-il quand cette fonction Main sera exécutée ? est-ce lors du premier appel d'une fonction de la DLL ?
A quel thread appartient cette fonction Main ? à un thread propre à la DLL ?
Autre question : cette DLL contient une fonction PORT1_DataReceived qui est déclenchée sur l'événement DataReceived d'un port COM. A quel thread appartient cette fonction ?
Merci d'avance pour vos réponses.

Citation:

---

Envoyé par levalp

Bonjour,
J'ai une question au sujet de ma DLL.
Cette DLL contient un fichier program.cs, ce fichier contient une fonction Main. Quelqu'un sait-il quand cette fonction Main sera exécutée ? est-ce lors du premier appel d'une fonction de la DLL ?
A quel thread appartient cette fonction Main ? à un thread propre à la DLL ?
Autre question : cette DLL contient une fonction PORT1_DataReceived qui est déclenchée sur l'événement DataReceived d'un port COM. A quel thread appartient cette fonction ?
Merci d'avance pour vos réponses.

---

Salut Levalp,

le main d'une DLL (un assembly compilé comme bibliotheque de classe j'entends) n'est jamais executé implicitement, une DLL ne demarre pas, et n'est pas executé, c'est un recueil de classe, point.

Si tu parles de ce DataReceived, c'est indiqué que le callback sera traité par un thread du pool (comprendre un thread quelconque).

Citation:

---

Envoyé par SirJulio

Salut Levalp,

le main d'une DLL (un assembly compilé comme bibliotheque de classe j'entends) n'est jamais executé implicitement, une DLL ne demarre pas, et n'est pas executé, c'est un recueil de classe, point.

Si tu parles de ce DataReceived, c'est indiqué que le callback sera traité par un thread du pool (comprendre un thread quelconque).

---

Salut,
Je ne comprends pas bien, car le Main de ma DLL va lancer un thread, donc ce code doit bien être exécuté quelque part ?

Concernant le DataReceived, je lis : "L'événement DataReceived est déclenché sur un thread secondaire lorsque des données sont reçues de l'objet SerialPort. Cet événement étant déclenché sur un thread secondaire et non sur le thread principal,..."
mais vu que pour moi c'est dans une DLL, dois-je comprendre qu'il s'agit dans mon cas du thread principal du programme appelant la DLL ?
merci d'avance

Citation:

---

Envoyé par levalp

Salut,
Je ne comprends pas bien, car le Main de ma DLL va lancer un thread, donc ce code doit bien être exécuté quelque part ?

---

Une DLL en .Net n'a pas à avoir de Main.

Comme l'ont indiqué SirJulio et BlueDeep, et je me permet d'insister parce que tu fais plusieurs fois la confusion dans cetet discussion, une DLL n'est qu'un ensemble de classes mises ensemble dans un même fichier ; ça n'a aucun rapport avec le concepts de thread, événement, AppDomain, etc. Ton problème (gestion de threads, Threadpool, etc.) serait strictement le même si ton code était entièrement compris dans une même assembly.

Salut Levalp,

pour etre plus explicite, vu qu'une DLL ne peut, structurellement, pas etre demarré (executé), c'est forcement un exe (console, windows whatever) qui va l'appeler. De fait, la problematique de threading est reporté vers cette assembly tierce (qui appelle, et comment ?). Simplifions le cas à l'"extreme :

-j'ai un exe console qui appelle des methodes de ma DLL.
-une DLL avec des methodes

si j'appelle ma methode de ma DLL en la threadant depuis mon appli alors l'appel se fera sur un thread tiers (poolé ou non). A contrario, si j'appelle ma methode directement, l'appel se fera sur le thread ayant demarré mon appli (qu'on pourrait appeler le thread principal).

Que ta DLL contienne ou non un main ne change pas le probleme (une dll peut avoir un main ce n'est pas interdit juste inutile), un assembly compilé en /out:Library (donc ce qu'on appelle une DLL) ne peut pas etre demarré, il sera juste parcouru par les autres assemblies faisant des appels dessus.

Pour le Datareceived, je ne sais pas trop comment ca marche, mais j'imagine que tu dois initialiser la classe et la classe emet des events (datareceived ici) quand elle entends quelque chose. Les callbacks de ces events seront executés par un thread du pool (au meme titre qu'un timer si tu veux, tu init un timer les callback d'elapsed sont levés par un thread tiers).

Bref, dans une DLL, si cette derniere ne créé pas explicitement de thread (new thread blabla) ou implicitement (le datareceived par exemple, mais aussi des methodes async quelconque), la problematique du thread est reporté vers l'appelant.

En esperant avoir ete plus clair. =)

Citation:

---

Envoyé par Bluedeep

Une DLL en .Net n'a pas à avoir de Main.

---

Citation:

---

Envoyé par Guulh

Comme l'ont indiqué SirJulio et BlueDeep, et je me permet d'insister parce que tu fais plusieurs fois la confusion dans cetet discussion, une DLL n'est qu'un ensemble de classes mises ensemble dans un même fichier ; ça n'a aucun rapport avec le concepts de thread, événement, AppDomain, etc. Ton problème (gestion de threads, Threadpool, etc.) serait strictement le même si ton code était entièrement compris dans une même assembly.

---

Bonjour Bluedeep et Guulh,
Merci pour ces précisions. je crois que maintenant j'ai compris comment ca fonctionne.

Citation:

---

Envoyé par SirJulio

Salut Levalp,

pour etre plus explicite, vu qu'une DLL ne peut, structurellement, pas etre demarré (executé), c'est forcement un exe (console, windows whatever) qui va l'appeler. De fait, la problematique de threading est reporté vers cette assembly tierce (qui appelle, et comment ?). Simplifions le cas à l'"extreme :

-j'ai un exe console qui appelle des methodes de ma DLL.
-une DLL avec des methodes

si j'appelle ma methode de ma DLL en la threadant depuis mon appli alors l'appel se fera sur un thread tiers (poolé ou non). A contrario, si j'appelle ma methode directement, l'appel se fera sur le thread ayant demarré mon appli (qu'on pourrait appeler le thread principal).

Que ta DLL contienne ou non un main ne change pas le probleme (une dll peut avoir un main ce n'est pas interdit juste inutile), un assembly compilé en /out:Library (donc ce qu'on appelle une DLL) ne peut pas etre demarré, il sera juste parcouru par les autres assemblies faisant des appels dessus.

Pour le Datareceived, je ne sais pas trop comment ca marche, mais j'imagine que tu dois initialiser la classe et la classe emet des events (datareceived ici) quand elle entends quelque chose. Les callbacks de ces events seront executés par un thread du pool (au meme titre qu'un timer si tu veux, tu init un timer les callback d'elapsed sont levés par un thread tiers).

Bref, dans une DLL, si cette derniere ne créé pas explicitement de thread (new thread blabla) ou implicitement (le datareceived par exemple, mais aussi des methodes async quelconque), la problematique du thread est reporté vers l'appelant.

En esperant avoir ete plus clair. =)

---

Salut SirJulio,
C'est plus clair, en effet. Merci pour tes précisions.