Bonjour Fred,
Désolé pour la réponse tardive, j'étais 'out of office cette semaine' et sans accès internet.
Je vous conseille de jetter un oeil sur les timers asynchrones, lesquels permettent de plannifier l'éxécution d'une fonction de manière périodique dans un thread à part.
Concernant la manière de structurer votre code, je la trouve étrange, mais ne l'ayant pas testée, je ne saurai dire à 100% si elle doit fonctionner. Cependant, je ne vois rien qui me ferait dire que votre manière de coder ne fonctionerait pas. Ceci dit, voici comment je procèderai.
1. Un thread pour l'interface utilisateur (le thread par défaut)
2. Un thread pour l'écriture sur disque (l'écriture sur disque doit en effet être séparée de l'acquisition)
3. Autant de thread que nécessaires (8 d'après ce qe vous écrivez précédemment) pour vos différentes acquisition (cependant, vous est-il nécessaire de faire 8 threads différents ?). Chacun de ces threads se résumera à l'acquisition proprement dite, et à l'envoi des données acquises vers un organe de dialogue inter-thread (sorte de tampon)
Le but de tout ceci étant de ne jamais bloquer votre acquisition (que l'enregistrement des données sur le disque ou que l'interface utilisateur soit bloquée n'a aucune importance, mais que l'acquisition soit bloquée posera tôt ou tard des problèmes)
Pour la communication inter-thread, utilisez les thread safe queue avec une taille dynamique. Le mécanisme de lock est déjà inclu dans une thread-safe queue et en taille dynamique, vous ne rencontrerez aucun problème quels que soient les blocages éventuels des threads qui viennent lire les informations dans la queue (et 'vider' la queue). La seule limite possible serait de bloquer le thread lecteur (la queue ne ferait alors que de se remplir) jusqu'à éclater votre RAM de PC...
Concernant le nombre max de thead que vous pouvez créer, il est certainement bien plus grand que ce dont vous aurez besoin. Par contre, par pool (sorte de groupement de threads), vous ne pouvez pas en avoir autant que vous le souhaitez. Le nombre est limité (de tête, mais la formule exacte est repris dans le document il me semble) à 2*nb de processeurs + 2. En l'occurence, cela veut dire que sur une machine monoprocesseur, vous pouvez avoir 4 threads par pool. Pour faire tourner plus de threads en paralèlle, créez un nouveau pool de threads, et vous aurez 4 nouveaux threads disponibles.
En espérant que cela puisse vous aider. N'hésitez pas à poursuivre dans vos questions.
Cordialement,
Message Edité par Mathieu Steiner le 04-13-2007 03:41 PM