|
|
||||||||||||||||||||
|
Windows CE est un systême d'exploitation (SE) multi-thread. A ne pas confondre avec multi-process. On dit d'un SE qu'il est multi-process lorsqu'il est capable de faire tourner plusieurs applications simultanément. On dit d'un SE qu'il est multi-thread lorsque non seulement il est capable d'exécuter plusieurs applications mais qu'au sein de chacune d'elles, il est capable d'exécuter simultanément plusieurs fonctions. Je tiens toutefois à attirer l'attention sur le terme simultanément. En effet, jusqu'à preuve du contraire, un processeur n'est capable que de faire une seule chose à la fois. Le SE va donc s'arranger pour donner l'illusion que deux tâches s'exécutent parrallèlement. Pour ce faire il va partager le processeur entre tous les thread. Le temps est divisé en tranches infimes appellés quantum. L'algorithme qui détermine l'attribution des quantum aux threads est l'algorithme de scheduling. Ce dernier attribue le temps processeur en fonction des priorités des threads et des ressources détenues par eux. Le but de se document n'est pas de rentrer dans les détails du scheduler. Le passage d'un thread à un autre sur le processeur est appellé context switch ; Le context switching est une opération couteuse puisqu'elle consiste à sauvegarder l'état de la plupart des registres du processeur pour le thread sortant et de rétablir les valeurs des registres pour le thread entrant.. Dans la pratique, seuls les systèmes dotés de plusieurs processeurs peuvent physiquement exécuter plusieurs threads en parallèle : un par processeur en fait. La plus petite entité d'exécution sous Windows CE est donc le thread. Chaque application en cours d'exécution en contient au minimum un : le thread primaire. Il est créé en même temps que le process et il exécute toujours le point d'entrée de l'application (WinMain ou main la plupart du temps). Lorsque le thread primaire se termine, l'application se termine. Windows CE autorise un nombre maximum de 32 process simultanés.
Il n'existe par contre pas de limite pour le nombre de thread si ce
n'est une limite imposée par la memoire disponible sur l'appareil.
A partir du thread primaire, il vous est loisible de lancer de nouveaux
threads. La question qui vient tout de suite à l'esprit est :
" Puis-je lancer n'importe laquelle des fonctions de mon application
en thread ? " La réponse est non ! En effet une fonction
thread possède un prototype imposé. Elle doit toujours
être du type :
Pour créer un nouveau thread, on utilise l'API Win32 CreateThread dont voici le prototype :
CreateThread retourne un handle sur le thread. Celui-ci pourra être utisé plus tard pour par exemple détecter si le thread en question est terminé.
Une fois que vous avez lancé votre thread, se pose le problème
de sa longévité. Les règles sont simples : Ainsi donc si vous voulez garder un thread en vie durant toute la durée d'exécution de l'application, vous devrez nécessairement installer une boucle dans ce thread. Nous reviendrons sur ce point plus tard dans l'article.
Le handle d'un thread est dit signalé lorsque le thread s'arrête, il est non-signalé lorsqu'il est en cours d'exécution. Certaines fonctions Win32 de synchronisation comme WaitForSingleObject permettent d'attendre qu'un handle soit signalé. Je peux donc très facilement avec WaitForSingleObject attendre qu'un thread se termine. Cest le thème de mon premier exemple. Lorsque vous n'avez plus besoin du handle, il est de bonne pratique de le libérer au moyen de l'API Win32 CloseHandle.
Une seconde approche consiste à passer un paramètre au
thread via la fonction CreateThread. Dans ce cas vous êtes
autorisé à passer un LPVOID au thread. Si vous avez juste
une variable à passer au thread, passez directement cette dernière
en paramètre en prenant soin d'effectuer un cast de son type
vers LPVOID.
Globalement il y a deux manières d'arrêter un thread,
la bonne et la mauvaise :) . La seconde méthode (la bonne) consiste à faire parvenir
une notification au thread que l'on désire arrêter afin
de lui demander d'effectuer une sortie en douceur. Ceci n'est possible
que si le thread est en mesure de vérifier de manière
régulière qu'un tel message lui a été posté.
L'exemple ci-dessous illustre mon propos. Dans cet exemple, un thread
effectue de manière régulière une routine quelconque.
A chaque exécution de sa routine, il est en mesure de détecter
une demande d'arrêt de ses activités. La notification sera
faite en utilisant un évènement manuel.
Dans une seconde partie, je m'attacherai à la synchronisation
des threads. En effet, il est souvent le cas, que l'on doive agencer
l'exécution des threads en fonction d'évènements
extérieurs. Par exemple, un thread B ne commence à traiter
les données que lorsque le thread A a terminé de les recevoir.
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
Copyright 2001-2004 - Tous droits réservés
|
||||||||||||||||||||
|
iPAQ
est un produit de COMPAQ.
|