hello
 
j'ai un peu googlisé mais j'ai pas trouvé grand chose comme explications de "bases" sur le multitache windows sous delphi
 
d'abord, si j'ai bien tout compris, delphi met un disposition un objet TThread qui permet de ne pas avoir à utiliser d'API windows mais je ne comprends pas comment fonctionne la synchronisation entre plusieurs Threads: dans certains sites, j'ai lu qu'il fallait utiliser l'API windows, dans certaines sources, j'ai trouvé des "TSemaphore", par contre, pas de boites aux lettres en vue; bref, je nage un peu
 
si qqun a une adresse (francophone si possible, soyons fou) je suis preneur
 

y a une procédure Synchronize à laquelle tu peux passer l'adresse d'une procédure à exécuter.

bon, me revoilà avec mon problème de multitâche apres qq jours d'étude, voilà ce que j'ai :
 

• une carte d'acquisition NI
• un application multitâche delphi

l'acquisition se fait à l'aide de composants posés sur une form, cela signifie-t-il que les handlers de ses composants sont exécutés dans la tâche mère
si oui, quelle est la priorité de la tâche mère
toujours si oui, sachant que ses handlers attendent un jeton d'un sémaphore utilisé par une autre tâche de priorité tpHigher est ce que le fonctionnement est (comme je le suppose) bancal
 
(apparement, l'application "loupe" des valeurs de temps en temps, c'est pour ça que je m'interroge ^^)
 
 
 

 
merci bien, je vais essayer de voir ça dans la doc

tes recherches sur google ont du te faire tomber sur ce tutorial en anglais je suppose mais je le donne pour ceux qui seraient intéressés

Tu peux regarder [http://delphipage.free.fr/threads.html]ici[/url]

merci bien, j'ai posté une copie de ce topic là bas

Oooops, dsl  

help, j'aimerais avoir une petite confirmation
 
est ce que les handlers des composants sont exécutés avec la même priorité que la tâche principale et est ce que la tâche principale a une priorité normale par défaut

je crois que c'est oui pour les deux questions

merchi
 
je vais essayer de faire un test avec des tâches différentes avec priorité plus forte, ça marchera peut être mieux

 
les handlers des composants    
 
Y a qu'un seul thread qui s'occupe des messages pour les composants, c'est le thread principal (d'ou le foirage total si on commence à modifier des compos visuels dans un autre thread). Tu peux modifier la priorité de ton thread avec SetThreadPriority et tu pourrais l'appliquer au thread principal, mais faut voir si l'utilisateur va apprécier    
 
Dans ton cas, je sais pas si c'est toi ou le compo qui qui vérifie si y a des trucs à lire sur la carte... si c'est toi (admettons que ce soit le cas) et que le compo que tu utilises n'est pas visuel (donc si c'est juste une icone sur un form en design time à priori c'est bon), crées le dynamiquement dans un thread, comme ca si ton application est "bloquée" a un truc plus ou moins important, tu peux tjs espérer que ton thread lise les infos de ta carte  
 
J'espère que ca aidera au moins un peu  

ce que j'appelle "handler de composant", ce sont les procédure événementielles des composants (ça me fait penser à des handlers )
 
ce que j'aimerais faire, c'est que ces procédures, au lieu de se tapper tout le traitement, ne fasse qu'activer une tâche de priorité maximale qui elle ferait le traitement
 
je sais pas encore quel méthode de synchronisation utiliser: les sémaphores que j'ai vu ne servait qu'à ouvrir et fermer des sections critiques, je crois bien que je vais être obligé d'utiliser cette méthode synchronise à laquelle je comprends rien ^^ à moins que je trouve des méthodes pour endormir/réveiller des tâches

T'as toujours pas été très explicite sur les compos, mais à priori pour une gestion d'un port ca doit pas être un compo visuel, tu peux très bien le créer et assigner les events dans un thread...

oui oui, c'est bien un compo non visuel

ya un truc que je comprends pas trop avec la méthode synchronise
 
si j'ai bien compris, on appelle cette méthode quand depuis un thread on veut attendre la fin d'une procédure exécutée par le thread principal pour poursuivre l'exécution dudit thread
 
le probléme, c'est que je veux faire l'inverse (depuis le thread principale, s'arrêter tant qu'une tâche n'a pas terminé son traitement)
 
je crois que je vais choisir la méthode de Zion (créer les composants dans une tâche dédiée)

 
Benh si t'as compris, le principe de la méthode synchronize c'est d'envoyer un msg au thread principal avec l'adresse de la fonction à appeler (ce qui limite à des procédure sans arguments), et ce sera traité quand y aura plus rien à faire vu que le handler des messages (sauf si tu l'apelles toi même comme un bourrin) n'est apellé que quand on est sorti de toute imbrication de fonction dans le thread principal (pfiouf).
 
Donc oui, tu dois faire un thread, créer ton compo dans le thread et faire une boucle infinie dans le thread en apellant une fonction bloquante (genre une attente d'un mutex ou d'un event)...  
 
Enfin bon, tu vas t'amuser  

 
comme ça
 

 
parce que yen a plein partout dans le code que je dois débugger
 
j'ai une autre question, malgré mes recherches, je trouve de boites aux lettres .... comment je peux traduire boite aux lettre en anglais (à part mailbox et message queue) parce que google il trouve rien
 
Dans le cas où je trouverais vraiment rien, est ce que c'est raisonnable de créer une classe BaL avec un TObjectList protégé par un sémaphore

oué le ProcessMessages... Ca va le faire le synchronize direct la  et adieu monde cruel parfois  
 
Pour le sémaphore, faut voir, tant que tu risques pas d'avoir 2 threads qui se bloquent l'un l'autre ca va  

bon, j'en ai marre de pinailler à chercher les bugs
 
je vais refaire du code qui marche  
 
merci pour ton aide

hello
 
si je crée un composant non visuel dans une tâche, qu'est ce que je mets dans le paramètre AOwner de son constructeur

si tu le libères manuellement après, tu peux mettre nil
si tu mets Application ou le nom de la Form peut-être qu'elle se charge de le virer mais j'en suis pas sûr (faut peut-être aussi le parent ?)

TMultiReadExclusiveWriteSynchronizer
 

 
 
pourquoi pas
 
TMultiReadExclusiveWriteSynchronizerSoThatSeveralThreadsCanReadAsLongAsNoOneIsWrinting
 

 
antp:
finalement, j'y ai mis sur une forme, je verrai plus tard si je les met dans le thread