Discussion :

[davidif]

Bonjours,

ce que j'ai compris est que cette notion permet de faire travailler plusieurs tâches en parallèle.

Donc comme il m'a été décrit, deux fonctions dans deux thread différent fonctionne indifféremment en parallèle, on peu faire appel a une fonction dans un thread différent ou réciproquement si je me trompe pas, l'évocation de invoke().

Afin de comprendre au mieux cette notion de thread pour mieux intervenir dessus:

combien de thread peut-on avoir dans un programme, comment les identifiés et comment fait-on référence à un thread particulié en faisant un invoke().

Auriez vous des liens ou reférence à me conseillé pour mieux comprendre cette notion.

Merci

[Médinoc]

Invoke() ne marche que pour Windows Forms (Framework .Net), et plus précisément pour les threads qui affichent des Windows Forms.

La classe System::Windows::Forms::Control, la classe mère de tout ce qui est affichable en Windows Forms, possède cette méthode Invoke() qui appelle la fonction reçue en paramètre sur le thread propriétaire du contrôle (c'est-à-dire, le thread qui l'a créé).

Pour reproduire ce genre de comportement ailleurs, il faut utiliser des objets de synchronisation, comme (à partir du Framework 4.0) BlockingCollection dans le sens des appels et des événements dans le sens des retours.

[davidif]

Merci pour tes explications Médinoc, faut que je continu à me pencher sur cette environnement pour en saisir la subtilité.

Aurais-tu des références à me conseiller pour quelqu'un comme moi qui possède que des notions de C microproce et pascal(delphi) en tant qu'électronicien.

[bacelar]

Google est l'ami de l'humanité.

http://fr.wikipedia.org/wiki/Thread_(informatique)

[davidif]

Ca je me doute bien que google à toutes les réponses que ce pose l'humanité, seulement y a tous et n'importe quoi et ma question était orienté par rapport à une expérience personnel de quelqu'un d'expérimenté.

J'ai évidemment fais mes recherches sur le net.

Merci pour le lien

[bacelar]

expérience personnel de quelqu'un d'expérimenté

Me voila habillé pour l'hiver.

J'ai donné une référence généraliste car il faut commencer par cela.

Vous ne comprendrez le cloisonnement des appels liés au "thread appartements" et à l'affinité de thread des contrôles Windows que si vous avez une idée claire de ce qu'est un thread en général.

Pour faire concis, un processus n'est qu'un espace virtuel d'adressage.
Quand vous lancer un programme vous créez ce bac à sable qu'est un processus (avec le code machine du fichier programme dans un coin de l'espace d'adressage) et un thread, qui l'utilise, avec un IP (Instruction pointer), stack pointeur, .... (tout ce qui est spécifique à un thread, donc pas l'espace d'adressage ou des handler de fichier qui font partie du bac à sable eux).

Le thread est "ce qui tourne", mais rien ne vous empêche de créer un autre dans le même espace d'adressage (même processus), mais avec un autre IP.
C'est là que des mécanismes sont utilisés pour empêcher que chaque thread ne foute le Bronx dans les données utilisées par un de ces congénères.

Pour éviter toute embrouille, les contrôles Windows n'acceptent, en générale, les appels de fonction que le thread l'ayant créé (le controle).