Discussion :

[Mastero]

Bonjour j'ai créé un thread de travail (lancé par la fonction AfxBeginThread) et je souhaite mettre une pause à son exécution. Comment peut on faire?
Merci d'avance

[Mac LAK]

Le forum "Visual C++" aurait été plus adapté à ta question.

Fonction SuspendThread de l'API Win32, ou CWinThread::SuspendThread suivant le cas.
Tu peux les appeler aussi bien depuis le thread lui-même que depuis un autre thread.

[Mastero]

Cela aura t il pour effet d'arrêter le thread ou peut on le faire repartir à notre gré?
Est ce qu'on pourrait faire pareil avec des Event, on fait attendre un event qui est lancé quand on relance le thread?

[farscape]

salut,
oui
une fois suspendu le thread peut redemarrer avec ResumeThread.
oui tu peux bloquer ton thread avec un event.
exemple d'utilisation d'event dans la faq:
http://c.developpez.com/faq/vc/?page...opWorkerThread

regarder aussi l'utilisation d'un event pour la reception de données par voie serie. (voir lien dans le post cite)
le thread est bloqué tant que l'on ne recoit pas de caracteres..

[Mac LAK]

Pour rajouter un "grain de sel" : suspendre un thread par SuspendThread est relativement "brutal", car il s'arrête là où il est, et surtout quoi qu'il soit en train de faire !!

Bref, tout va bien si le travail effectué par le thread est indépendant d'une quelconque ressource externe (ex : thread de calcul "pur", compression, cryptage, etc...), et que le "top finish" est donné par la fin du thread lui-même. Dans ce cas, ça ne fait que ralentir la complétion du travail, c'est tout.

Si, par contre, ton thread ne peut/doit être arrêté qu'à certains endroits bien précis, alors un évènement est indispensable car c'est le seul moyen de ne l'interrompre qu'à certains endroits prédéterminés : le "truc", c'est à chaque fois d'attendre un évènement avec un timeout infini, cet évènement étant par défaut toujours signalé et "manuel". Si le thread principal "annule" l'évènement, le(s) thread(s) correspondant(s) sera(ont) suspendu(s) après complétion de l'"atome" de calcul en cours. Il(s) repartira(ont) dès que le thread principal aura de nouveau signalé l'évènement.

[Mastero]

En fait j'ai une série d'images en mémoire dans une liste chaînée et je souhaite pouvoir les lire et faire des fonctions de magnétoscope.
Je souhaite pouvoir lire la séquence d'une traite ou bien de pouvoir faire une pause ou faire revenir en arrière ou image par image. J'ai vu les exemples sur le FAQ Visual C++ notamment celui du programme de service
J'ai vu aussi que tu pouvais faire un WaitForSingleObject sur un Thread est ce que cela peut marcher avec les fonctions SuspendThread et ResumeThread?
Si ma fonction de thread est en attente d'une action, elle va se suspendre elle même et attendre que l'utilisateur presse le bouton pour attendre le ResumeThread.

[Mac LAK]

En fait j'ai une série d'images en mémoire dans une liste chaînée et je souhaite pouvoir les lire et faire des fonctions de magnétoscope.

Donc, les évènements sont à priori préférables pour toi, car tu dois faire tes pauses "frame par frame", et avoir fini d'en décoder une pour pouvoir te mettre en "pause" de manière saine.

J'ai vu aussi que tu pouvais faire un WaitForSingleObject sur un Thread est ce que cela peut marcher avec les fonctions SuspendThread et ResumeThread?

Non, WFSO sur un thread, c'est pour attendre la terminaison du thread, pas le fait d'attendre qu'il soit suspendu.

Si ma fonction de thread est en attente d'une action, elle va se suspendre elle même et attendre que l'utilisateur presse le bouton pour attendre le ResumeThread.

C'est ce que fait WFSO : il attend "quelque chose", la nature de l'attente dépendant de la nature du handle passé en paramètre.
Pour un évènement, ça attend qu'il soit signalé. Pour un thread ou un processus, ça attend la fin du thread/processus. Pour un mutex, ça attend qu'il soit libre et ça le prend au passage (idem pour les sémaphores). Etc, etc, etc.
En fait, un WFSO "en attente", avec un timeout infini par exemple, est exactement équivalent à un SuspendThread, mais à "Resume automatique"... Avec les fonctions SuspendThread/ResumeThread, il faut qu'un AUTRE thread gère le contrôle, au moins pour le ResumeThread en tout cas !!

Est-ce un peu plus clair pour toi ?

[Mastero]

Une question pour confirmation, est ce qu'à chaque reception d'un SetEvent on doit faire un ResetEvent?

[Mac LAK]

Si l'évènement est "manuel" (paramètre bManualReset==TRUE), oui, sinon c'est automatique.
Tu décides ça à la création de l'event, cf. CreateEvent sur MSDN.