Discussion :

[cedricgirard]

Bonjour,

Je cherche à désynchroniser certains traitements dans mon application. Par exemple
- réception ordre via le réseau et exécution de cet ordre
- ajout d'une ligne dans le journal et affichage du journal à l'écran

Mais je souhaite éviter tant que possible les threads qui masquent une partie de la compléxité en en créant une autre.
Certaines librairies, ICS par exemple, sont non bloquantes, mais je ne sais trop comment faire (je me plonge actuellement dans le code ICS, qui n'a rien de petit) donc si qq a pondu un article ou a quelques pistes/conseils, merci d'avance.

Cordialement
Cédric

[anapurna]

salut


ICS utilise les message windows
il ne te reste donc plus qu'a creer tes propre message au sein de ton application


@+ Phil

[Reisubar]

Mais je souhaite éviter tant que possible les threads qui masquent une partie de la compléxité en en créant une autre.

Pour des communications réseau, le mode bloquant est le plus "naturel" et à mon avis le plus cohérent. Je ne vois pas en quoi un thread masque la complexité : au contraire, il permet de conserver un code procédural, facile à maintenir.

Certaines librairies, ICS par exemple, sont non bloquantes, mais je ne sais trop comment faire (je me plonge actuellement dans le code ICS, qui n'a rien de petit) donc si qq a pondu un article ou a quelques pistes/conseils, merci d'avance.

Le principe est simple : répondre dans les gestionnaires d'évènements implémentés par ICS. Sur le site de François Piette il y a de la doc et une mailing list assez active, tu devrais essayer de ce côté en cas de problèmes.

[cedricgirard]

Merci pour vos réponses

ICS utilise les message windows
il ne te reste donc plus qu'a creer tes propre message au sein de ton application

Justement je cherche un petit truc pour commencer sur les messages, les pièges courants à éviter par exemple, des conseils tirés de l'expérience. Toutes choses pas évidentes à lire dans un code qui fait bien d'autres choses.

Pour des communications réseau, le mode bloquant est le plus "naturel" et à mon avis le plus cohérent. Je ne vois pas en quoi un thread masque la complexité : au contraire, il permet de conserver un code procédural, facile à maintenir.

Sauf que mon but n'est pas de faire de la communication réseau, mais de faire comme ICS. Quant au mode bloquant, il est le plus simple à comprendre, tout simplement. Ce qui est naturel est ce que l'on a appris, pas ce qui est réellement le plus cohérent.
Ceci dit un thread impose des verrous d'accès aux espaces mémoires partagés qui dans l'actuelle version de l'appli posent pas mal de soucis : il est facile d'oublier de protéger une section importante, on a eu quelques cas d'interblocage entre threads totalement indébugables... bref tous les conseils que j'ai reçu reviennent à utiliser des messages, que ce soit avec ou sans les threads. Si je n'ai pas besoin d'eux, je préfèrerai m'en passer et controler moi même la compléxité plutot que de la confier à une boite magique qui me laisse parfois au milieu de la route.
Autre soucis : je dois assurer un relatif temps réel sur certains points, et je ne veux pas que l'OS réactive à ce moment là un thread non prioritaire, ce qu'il peut faire de manière relativement aléatoire si j'ai bien compris. La précision recherchée est de l'ordre de la milliseconde, ce qui marche très bien pour le moment.

Tu préfère le mode bloquant, je préfère éviter les threads, chacun ses goûts.

Le principe est simple : répondre dans les gestionnaires d'évènements implémentés par ICS. Sur le site de François Piette il y a de la doc et une mailing list assez active, tu devrais essayer de ce côté en cas de problèmes.

Sauf que je ne cite ICS que comme un exemple, je veux faire comme ses composants. Pour ce qui est de l'utiliser c'est très simple, même si elle est non-bloquante et asynchrone.

[cedricgirard]

- réception ordre via le réseau et exécution de cet ordre
- ajout d'une ligne dans le journal et affichage du journal à l'écran

Je vais préciser ma quête, qui n'est clairement pas claire.

Quand un message arrive via le réseau, il provoque un traitement qui peut être un peu long. Hors je ne veux pas que le réseau attende que ce traitement se termine pour reprendre son activité.

De même, quand j'ajoute une ligne de log, je ne veux pas attendre que l'IHM se soit rafraichit (ce qui est horriblement long à l'échelle du programme) pour continuer le travail. Tant pis si un léger décalage se produit dans l'affichage, l'humain ne s'en rendra jamais compte.

Au final je me rend compte qu'un thread avec des messages, en banissant strictement les espaces mémoires partagés et donc les verrous/sémaphores, pourrait peut être faire l'affaire. A tester niveau temps réel.

[glayag]

Quand un message arrive via le réseau, il provoque un traitement qui peut être un peu long. Hors je ne veux pas que le réseau attende que ce traitement se termine pour reprendre son activité.

A part de passer par l'utilisation des threads, je ne vois vraiment pas comment tu peux faire...

Autre soucis : je dois assurer un relatif temps réel sur certains points, et je ne veux pas que l'OS réactive à ce moment là un thread non prioritaire, ce qu'il peut faire de manière relativement aléatoire si j'ai bien compris

C'est pas totalement aleatoire.
Aleatoire au point de vue du programme mais pas du point de vue du systeme.
Chaque thread dispose d'un temps limite suivant la priorite que son process a.
Si tu veux avoir un maximum de temps pour toi pour reagir des qu'il le faut, il suffit d'augmenter la priorite de ton process.

[cedricgirard]

A part de passer par l'utilisation des threads, je ne vois vraiment pas comment tu peux faire...

Justement, avec des messages, c'est possible. Des librairies le font, donc ICS. Je connais la théorie, et je cherche la pratique. J'ai trouvé quelques articles sur le site de Michel Bardou, mais comme la dernière fois que j'ai posté un lien vers mon site j'ai été censuré parce qu'il contient un forum tout vide... j'hésite

C'est pas totalement aleatoire.
Aleatoire au point de vue du programme mais pas du point de vue du systeme.
Chaque thread dispose d'un temps limite suivant la priorite que son process a.
Si tu veux avoir un maximum de temps pour toi pour reagir des qu'il le faut, il suffit d'augmenter la priorite de ton process.

Tu sais, l'avis du système je m'en tamponne un peu. L'important c'est que mon programme fonctionne correctement. Et je n'ai pas tant besoin de réagir que de garantir que telle tâche s'exécutera à 15:30:21:150, et que la suivante sera précisément à 15:30:21:750, soit une demi-seconde plus tard, à une milliseconde prêt. Et pour ça, faut pas qu'un autre thread gagne brusquement le droit de faire quelque chose parce que ça fait 1H qu'il attend.
Précision : seul ce programme tournera sur la machine, et elle sera allégée de tous les services quasiment, tunné pour une seule tâche précise.

[anapurna]

salut


as tu essayer le design pattern "observer" ?

je pense qu'il convient tout a fait a ton type d'application
tu creer un buffer d'arriver et a la fin de ton remplissage
tu declenche un evenement qui d'eclenche un autre evenement

@+ Phil

[cedricgirard]

salut


as tu essayer le design pattern "observer" ?

je pense qu'il convient tout a fait a ton type d'application
tu creer un buffer d'arriver et a la fin de ton remplissage
tu declenche un evenement qui d'eclenche un autre evenement

@+ Phil

Oui, effectivement ça semble pas loin de ce que je veux faire.