Discussion :

[buzzz]

voila j'ai un peripherique que je controle par un controle activex

l'application est une fenetre MDI qui peut generer differentes actions
sur ce peripheriques.

Habituellement pour gerer les conflits de partage => semaphore

ici c'est differente car je veux que le dernier process appelant (une fenetre pour moi) prenne la main sur le periph et que l'autre recoit l'ordre de se retirer.

Je ne vais pas chercher a kicker le processus maitre ancien car s'il est en train de communiquer avec le controle activex ca pourrait le planter definitivement. Il est plus sage qu'il termine sa tache courante et qu'il perde la main dessus.

exemple :

periph *

processus 1 :
for (i=1 ; i < 100 ; i++)
periph->EmettreSon();

processus 2 :
for (i=1 ; i < 100 ; i++)
periph->EmettreSon();

L'utilisateur declenche process 1 => sons sortent
puis sur le 2

je veux
- que 2 attende la fin de l'appel a Emettre son de 1 (pour ne pas planter le controle activeX)
- que 1 perde la main sur le peripherique cad que soit Emettre son leve une erreur ou que le prochain appel a emetre son genere une erreur
- que 2 prenne la main

je veux eviter qu'au prochain appel de la boucle de 1, 1 reprenne la main comme 2 l'avait pris. Normalement ca serait plutot un probleme de semaphores ??? quoiqu'il est etrange je trouve ???

j'ai vraiment penser a faire des trucs etranges car pratiques

par exemple une fonction Priorite qui suivant le process appelant renvoit un pointeur sur le driver du peripherique ou sur un driver muet qui ne fait rien (le process 1 interogerait alors un driver vide qui ne fait que renvoyer des erreurs).

[Aurelien.Regat-Barrel]

Tu as réellement plusieurs process oubien tu te mélanges les termes process / fenêtre ?

[Caine]

Bonjour,
C'est un problème de mutex plus que de partage de mémoire entre processus.

Le premier processus ayant besoin de l'accés au périphérique créer un mutex avec CreateMutex, nommé, c'est ici qu'est la subtilité.

Pour le deuxième processus deux choix:
Créer un mutex avec le même nom que le premier processus. Ainsi CreateMutex renverra le handle du mutex créer par le prmier processus.
Ou si tu es sur que le mutex existe déjà, utiliser DuplicateHandle avec toujours le même nom de mutex.

Voilà, première phase bouclée, les deux processus se synchroniseront avec le même mutex.

Maintenant un processus demande le mutex, pour ne pas rester bloquer tu peux faire un WaitSingleObject :

DWORD WaitForSingleObject(

HANDLE hHandle, // handle of object to wait for
DWORD dwMilliseconds // time-out interval in milliseconds
);

pour dwMilliseconds tu mets zéro. Ainsi tu teste si tu peux prendre le mutex ou non sans être bloqué. Tu es bloqué, le cas du deuxième processus, tu envoies un évènement maison au premier processus pour qu'il te libère la ressource.

Pour ce genre de code, un bon exemple ici:

http://www.microsoft.com/belux/nl/msdn/community/columns/ldoc/multithread2.mspx

[buzzz]

Tu as réellement plusieurs process oubien tu te mélanges les termes process / fenêtre ?

j'ai une application MDI, lorsque je clique sur certains boutons des fiches, je genere un thread pour effectuer le traitement en parallele.

Petite question :
process : programme principal (le .Exe la winmain ?)
thread : sous-processus enfant
c'est bien cela ?

ok pour les mutex, mais en fait mon cas est plus complexe et je ne sais pas comment le gerer. Disons que j'ai deux threads (ecritures) qui accedent a une meme ressource (un driver). Ils se declenchent par demande de l'utilisateur. L'utilisateur est sensé etre naif et donc il peut declencher une nouvelle fonction sans que la precedente soit finie. Ainsi j'aurais aimé avoir un comportement de "voleur".

Thread A tourne
demande de l'utilisateur d'activer thread B
cette demande attend que A finisse sa requete au driver (la je pense c'est un simple mutex) et ensuite A est censé s'auto detruire (??)
Apres que A soit out, B prend la main sur le driver

[Aurelien.Regat-Barrel]

Probleme classique d'accès multiple à une ressource. Plusieurs possibilités (Mutex, Semaphore, Event, section critique,...) mais le plus simple est de détecter qu'une opération est en cours et de refuser d'en démarrer une nouvelle.
Je sais pas comment est conçu ton logiciel. Il faudrait avoir un objet moniteur qui s'occupe d'accéder au driver. Partout dans ton programmes tu utilises ce moniteur pour accéder au périphérique au lieu d'attaquer directement le périph. Ton moniteur étant le point central unique d'accès à ta ressource, il est facile ensuite de gérer un accès exclusif unique.

Au passage, un process est composé d'un ou plusieurs thread. Faut pas mélanger thread / process (en particulier le terme sous-process enfant j'aime pas trop personnelement). Un thread c'est un thread, Y'a pas de relation père-fils dans les thread. Les thread d'un même proces peuvent accèder à toutes les données du process. En revanche un process a son propre espace d'adressage, les autres process peuvent pas lire dedans.

[buzzz]

hum

pour le systeme d'ex j'en suis reste au cours d'unix et il me semble que pour l'exemple du while ( fork() ... ) on parlait de fils et de pere (de quoi je sais plus)

[Aurelien.Regat-Barrel]

fork crée effectivement un processus fils. Mais fork n'existe pas en Win32, on préfère utiliser des thread (CreateThread).