Discussion :

[levalp]

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.

[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

[levalp]

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 ?

[LaChips]

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

[levalp]

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 ?

[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.

[levalp]

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.

[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.

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.

[SaumonAgile]

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.

[levalp]

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

OK

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 ?

[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.

[levalp]

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.

[SaumonAgile]

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

[levalp]

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 ?

[SaumonAgile]

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.

[levalp]

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

[levalp]

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.

[Kaidan]

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.

[levalp]

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.

[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 ?