Discussion :

[buzzz]

j'ai parcouru les pages d'info sur les mutex windows
j'ai cru comprendre qu'un mutex devait etre utilisé a l'interieur d'un processus et pourtant a chaque fois j'ai cru comprendre que si on l'identifiait par un nom... le handle etait commun a tous les process...

personnellement cela m'arrange mais me pose un probleme
en effet je suis sensé faire un jour un releasemutex lorsque le programme se termine par exemple pour liberer la ressource.

Si a ce moment la un thread d'un autre process fait un WaitForSingleObject sur le handle qui est released donc normalement sans aucun sens... je vais avoir un plantage...

Cela signifierait qu'un tel type de mutex (associé a un nom et partagé entre tous les process) ne peut etre released un jour sans risque ?

[Aurelien.Regat-Barrel]

Tu n'as pas compris le fonctionnement des mutex. Mutex = verrou. Celui qui tient le mutex empêche les autres de le prendre. ReleaseMutex ne détruit pas le verrou, il le libère pour que quelqu'un d'autre puisse le prendre. Un handle de mutex est détruit via CloseHandle. Donc si un autre process fait un Wait sur ton mutex, au pire il bloquera ton process tant qu'il n'aura pas fait le Release.
Mais un autre process ne peut accéder à ton mutex que si ce dernier est nommé. Si tu ne lui donne pas de nom ben il peut pas récupérer de handle dessus vu qu'il sait pas comment le désigner, sauf cas spécial de processus fils qui hérité des handle de son père.
De plus les handle de ce type d'objets sont spécifiques à chaque process. Un autre process ne pas pas libérer ton handle, à moins que tu confondes process / thread.
Dans ton as (synchro entre thread), un seul CreateMutex suffit (par le thread principal, qui fera aussi le CloseHandle à la fin du programme). Tu mets le HANDLE du mutex anonyme dans une variable globale et tous tes thread l'utilisent directement.

[buzzz]

arf zut je me suis trompé

oui j'utilise un mutex nommé
donc normalement partagé entre process
le releaseMutex est ok

par contre ma question concernait en fait le close handle
J'ai un .Exe qui utilise un mutex nommé
si je lance deux fois ce programme, le mutex nommé
va bien se retrouver partager entre deux process ???
chacun fera un CreateMutex
et lorsque un programme sera ferme il declenchera un closeHandle

La question est, si createmutex compte ses appels, il faudra attendre la fermeture de la deuxieme appli pour avoir le closehandle qui liberera effectivement le handle.

Si createmutex ne compte pas ses appels, le handle sera libere au premier appel de closehandle, et le deuxieme programme, je sais pas ce qu'il va faire...

J'ai lu que parfois il fallait utiliser duplicatehandle (?) est-ce justement pour compter le nombre d'utilisation.

ps: excusez moi j'ai confondu releaseMutex et release (qui permet sous windows il me semble de liberer une ressource referencé par un handle)

[Caine]

Je vois.

Pour synchroniser deux processus il faut utiliser un mutex nommé.

Ainsi les deux process A et B demande l'accès à une même ressource et donc, un seul d'entre eux peut l'avoir a la fois.

Dans le Winmain ou dans un autre endroit approprié tu créais le mutex nommé, pour le nom je te conseille vivement une constante que ce partageront tout tes modules.

Dans un thread A :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
  
  Result = WaitForSingleObject(MutexHandle,0);
  
  switch(Result) {
     case WAIT_OBJECT0 :
        // Le driver est pris avec succès. Ton traitement ce rajoute ici.
     break;
     case WAIT_ABANDONNED:
        // Aïe, là c'est un problème grave, sortir évidemment.
     break;
        
     case WAIT_TIMEDOUT:
        // On peux par exemple s'endormir d'un temps déterminer à l'aide de SuspendThread.
     break;
 }

Tout les threads ayant accès à la ressource doivent copier ce code, ils seront ainsi synchronisés par le WaitForSingleObject.

Méthode deux :

Une variable de type booléen, partagée créer à l'aide de CreateFileMapping et nommée, je te laisse découvrir cette fonction par toi-même.

Tous les thread dans leur execute commencent par récupérer un Handle sur la zone partagée et ouvrir une vue avec MapViewOfFile.

Ils testent à chacun de leur cycle si cette variable vaut true ou false,si elle vaut false, il s'endorment d'un temps donné.

Ainsi tu es sur aussi que les threads se synchronisent sans consommer trop de temps CPU.

Voilà, je sais le multithreading et le multiprocess ne sont pas évident au début. Si je ne te paraît pas clair, n'hésites pas.

[Caine]

j'ai parcouru les pages d'info sur les mutex windows
j'ai cru comprendre qu'un mutex devait etre utilisé a l'interieur d'un processus et pourtant a chaque fois j'ai cru comprendre que si on l'identifiait par un nom... le handle etait commun a tous les process...

Inexact, le handle n'est pas commun car un variable même globale est allouée dans le heap d'un processus, une mémoire qu'il ne partage pas par défaut avec les autres processus. Le fait de nommer un mutex t'assure justement de le retrouvé et d'obtenir son handle, unique dans ce cas là.

personnellement cela m'arrange mais me pose un probleme
en effet je suis sensé faire un jour un releasemutex lorsque le programme se termine par exemple pour liberer la ressource.

Si a ce moment la un thread d'un autre process fait un WaitForSingleObject sur le handle qui est released donc normalement sans aucun sens... je vais avoir un plantage...

Non, WaitForSingleObject te retourne justement WAIT_ABANDONNED dans ce as précis.

Cela signifierait qu'un tel type de mutex (associé a un nom et partagé entre tous les process) ne peut etre released un jour sans risque ?

Non car chaque process ou thread qui veut utiliser ce mutex demande à le créer avec CreateMutes et donc récupère un handle valide dessus. Et à chacune de ces demande, un compteur de référence est incrémenté. Le handle est réellement libéré uniquement quand ce compteur de référence est à zéro. Et ce compteur de référence es décrémenté par CloseHandle.

ReleaseMutex ne fait que signaler aux processus(ou thread en attente) que le mutex est libre.

[buzzz]

Et à chacune de ces demande, un compteur de référence est incrémenté

merci c'est ce que je voulais savoir en fait

[Caine]

Même si je ne peux te donner un code complet pour l'instant, le seul en ma possession étant contractuel puisque propriété de mon employeur, les pistes que je te donne sont fonctionnelle, je les ai utilisées.

J'ai débuté aussi dans le monde merveilleux des thread Windows il y a six mois

[buzzz]

je te crois, c'est juste que la doc officielle msdn ne parle
pas vraiment de ce sujet, puisque la reponse a mon probleme
est plus liée au gestion des HANDLE systeme et ne figure
donc pas dans les fonction close et create des mutex

[buzzz]

WAIT_ABANDONNED

si je comprends bien ce cas ne doit pas arriver
si l'on fait correctement createmutex et closehandle

je ne vois pas dans quel cas un wait_abandoned se produit
et si je suis susceptible de le rencontrer et si je dois le gerer...

[Aurelien.Regat-Barrel]

Y'a 3 types de handle. Le fonctionnement des handle noyau est expliqué ici:
http://msdn.microsoft.com/library/en-us/sysinfo/base/handles_and_objects.asp
Tu devrais aussi lire la doc sur les mutex:
http://msdn.microsoft.com/library/en-us/dllproc/base/mutex_objects.asp
Dans ton autre post tu parles de thread uniquement. Cette fois tu as vraiment plusieurs process (CreateProcess) ou simplement des thread (CreateThread) ?

[moldavi]

Une URL sympa:

http://www.microsoft.com/belux/nl/ms...tithread2.mspx

[buzzz]

en fait j'ai 1 process
qui genere 2/3 thread

mais rien actuellement n'empeche de relation la meme application

et je me retrouve avec un mutex nommé si j'ai bien compris avec un mutex partage entre plusieurs process ?

(oui non ?)

merci pour les liens

[moldavi]

Ca c'est la partie 1 de l'url précédente. Je me demande si tu l'as regardé. Franchement tu as les réponses à tes questions et c'est largement abordable.


http://www.microsoft.com/belux/nl/ms...tithread1.mspx

[Aurelien.Regat-Barrel]

Si tu as juste des thread, ton mutex est automatiquement (comme n'importe quelle ressource de tout ton process) partagé par tous les thread. Un mutex anonyme fait l'affaire.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
HANDLE hMutex; // variable globale

void thread1()
{
    /* utilisation de hMutex */
    WaitForSingleObject( hMutex, INFINITE ); // acquérir le mutex
    // section critique
    ReleaseMutex( hMutex ); // libérer le mutex
}

void thread2()
{
    /* utilisation de hMutex */
    WaitForSingleObject( hMutex, INFINITE ); // acquérir le mutex
    // section critique
    ReleaseMutex( hMutex ); // libérer le mutex
}

int main()
{
    // créer le mutex
    hMutex = CreateMutex( NULL, FALSE, NULL ); // anonyme
    // créer les thread
    HANDLE hThreads[ 2 ];
    hThread[ 0 ] = CreatThread( /*thread1*/ );
    hThread[ 1 ] = CreatThread( /*thread2*/ );
    // attendre leur fin
    WaitForMultipleObjects( 2, hThreads, TRUE, INFINITE );
    // détruire le mutex
    CloseHandle( hMutex );

}

note qu'une section critique peut faire l'affaire (c'est plus performant qu'un Mutex).

[buzzz]

ok (oui j'ai lu ton lien)
merci a tous les deux
mais je viens de m'apercevoir que j'avais
foiré mon precedent message

originellement je programme avec c++ builder
qui empaquette les fonctions de l'api win 32
mes cours de systeme je les ai eus sous unix qui a une representation differente
et la doc que je trouve parle de l'api win 32 que je n'utilise pas directement a cause de delphi

faut m'excuser mais je suis contraint a faire un sorte de jonglage peu agreable parfois

donc OK pour les threads

ma question (ratée) dans le post precedent etait :

rien n'empeche le user de relancer le programme est d'avoir 2 fois mon appli qui tourne sur le meme pc en meme temps
si j'ai bien suivi cela fait 2 PROCESS qui partagent le meme peripherique en meme temps et donc cela implique => mutex nommé
ou alors je fais en sorte d'avoir une seule instance d'appli (j'ai le lien sur developpez ils utilisent d'ialleurs un mutex nommé)

question cote perf, c'est plus foudroyant la section critique ? ou c'est si lent un mutex ? je vais faire une centaine de requete dessus a la seconde environ

[moldavi]

rien n'empeche le user de relancer le programme est d'avoir 2 fois mon appli qui tourne sur le meme pc en meme temps

A mon avis mais peut-être que je me trompe...

Lorsque tu lances deux fois le même programme, le système d'exploitation alloue un espace d'adressage différent pour chaque processus.

Cela veut dire que chaque processus possède ses propres variables et autres.

Ceci veut aussi dire que les handles de mutex leurs sont propres.

Donc à ce niveau là pas de souci.

Le problème, c'est si vraiment ton programme utilise une ressource unique.

Exemple:

Ton programme, lors de sa création ouvre un fichier existant en mode d'écriture avec le flag "bloquant"(par exemple "toto.txt"). Et tu as décidé que ce fichier ne sera fermé que lors de l'arrêt du programme.

Si tu lances juste après le même programme, il va essayer d'ouvrir ce fameux fichier "toto.txt". Et là, ben impossible de l'ouvrir (à cause du flag "bloquant").

S'il n'y avait pas le flag bloquant, cela voudrait dire que les deux programmes écrivent en même temps dans "toto.txt". Je te dis pas le bordel.

Si ta situation correspond à ce cas là, alors oui faut faire quelque chose. Sinon et si tu prends tes dispositions, par exemple ouverture en mode bloquant, pas de souci.

Expliques-nous mieux ton cas. A quels types de ressources tu fais références?

[moldavi]

Si la ressource est un périphérique que tu ne "drives" pas, alors ce sera le système d'exploitation qui gèrera la chose, pas ton application.

[buzzz]

c'est une peripherique que je drive en bas niveau

pour regler ce probleme (comme celui de l'ouvertude de fichier)
un mutex nommé est bon non ?

[Aurelien.Regat-Barrel]

Avec un mutex anonyme effectivement plusieurs instances pourront être lancées et créer chacune son mutex. Mais je pense que c'est un 2° probleme, qui devrait être résolu autrement :
- empêcher de lancer plus d'1 instance de ton programme. Et pour cela on peut aussi utiliser un... mutex, nommé cette fois. Sauf que là c'est juste parce que c'est un objet kernel nommé, on peut utiliser un autre objet nommé. La 1° instance à son lancement crée le mutex nommé : c'est ok car il existe pas, tout va bien. La 2° instance teste le résultat de la création avec GetLastError et hop c'est ERROR_ALREADY_EXISTS (bien que le handle renvoyé soit valide) donc une autre instance tourne, donc message d'erreur "y'a déjà une autre instance" et hop on quitte.
- Si tu veux permettre à plusieurs instances de fonctionner en même temps, alors tu peux utiliser le mutex nommé comme moyen de synchro et non plus seulement comme moyen d'être informé qu'une autre instance tourne déjà.
Mais ça se complique... en effet, tu as une ressource système unique. Et si tu utilises un nom simple pour ton mutex nommé, ce dernier sera effectivement visible à tous les processus... d'une session. Et depuis WindowsXP, on peut avoir plusieurs utilisateurs connectés sur le même PC.
Pour que tous les utilisateurs voient ton mutex nommé, il faut que son nom commence par "Global\". Si tu veux partager ce mutex entre plusieurs utilisateurs (2° cas), y'a des problèmes de droits et ça se complique encore. Par exemple Administrateur se connecte et lance ton logiciel qui crée le mutex "Global\monmutex". Ok. Et puis toto, utilisateur restreint, se connecte et lance ton logiciel à nouveau. Il voit bien le mutex "Global\monmutex", mais comme c'est Admin (donc utilisateur avec + de privilèges que lui) qui l'a créé, ben tu peux pas t'en servir : => ERROR_ACCESS_DENIED. Alors faut se gérer les droits et c'est encore plus compliqué.
Si tu choisis le cas 1 (on se contente de tester s'il existe déjà et on refuse de lancer l'application), alors c'est plus simple. ERROR_ALREADY_EXISTS c'est que le programme torune déjà, ERROR_ACCESS_DENIED c'est qu'il tourne déjà dans une autre session. Hop tu quittes c'est fini youpi.
Enfin presque, car ça se complique encore un peu. Dans "Global\", y'a un antislash à la fin, et certaines versions de Windows refusent de créer un mutex avec un \ dans son nom (Win9x, WinNT). Alors il faut tester l'OS sur lequel tu tournes et construire le nom du mutex en fonction de ça. Sachant que l'option de compatibilité de WinXP permet de fausser ce test de version, faut quand même tenter la création et si ça échoue tester l'OS et adapter le nom...
Un bon lien sur le sujet:
http://www.flounder.com/nomultiples.htm (lire "The correct solution: Using a kernel object" et "Generalizing the Solution for NT").
Bon courage...

[buzzz]

ok merci bien pour tes details, ils me sont utiles
je viens de bosser ma soirée sur les fonctions de base des mutex

je viens de trouver 2 contradictions par rapport a la doc officielle :
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/waitforsingleobject.asp

enfin il me semble

il n'est pas precisé que les appels waitfor s'empile
car si l'on fait 2 waitfor sur le meme mutex, il faut faire
de release pour le liberer...

ensuite

WAIT_ABANDONED The specified object is a mutex object that was not released by the thread that owned the mutex object before the owning thread terminated. Ownership of the mutex object is granted to the calling thread, and the mutex is set to nonsignaled

je comprends par rapport a

WAIT_OBJECT_0 The state of the specified object is signaled

qu'un thread est mort tout en etant proprietaire d'un mutex, le mutex est libere MAIS reste "nonsignaled" donc non possédé, hors d'apres les tests que jai fait, il est possitionné a signaled cad que le process ayant fait le waitfor possede maintenant le jeton et les autres sont en stand by

pouvez vous confirmer ?