Discussion :

[buzzz]

autre probleme
j'ai fais ma classe mutex(char * name)
d'ou herite la classe "driver de peripherique"

la blague est que pour chaque instance de driver, je recrée un handle de mutex. Donc si j'ai dans le meme process trois threads qui communiquent avec le peripherique, je me retrouve avec

3 threads
3 drivers
3 handles sur le meme mutex

il me semble que l'on peut faire la meme chose avec un seul handle, mais la il faudrait que je l'initialise ailleurs (en debut de programme) et que je le relache ailleurs en fin. Avec ma solution les handle de mutex naissent quand j'instancie mon driver et meurrent en tant qu'objet automatique.

[Aurelien.Regat-Barrel]

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...

Mais on peut pas "empiler" les wait... Quand tu appelles Wait, ben ton thread est bloqué et ton code ne s'exécute plus, donc tu peux pas "empiler" un 2° appel.
Ensuite une fois que Wait te rend la main, tu acquières le mutex (sauf si timeout). Quand tu n'en n'as plus besoin il faut le libérer avec ReleaseMutex, sinon personne ne pourra l'acquérir. C'est le principe du verrou : si tu le possède, il tant que tu ne le déverouilles pas y'a que toi qui le possède.

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 ?

"nonsignaled" ça veut pas dire non possédé, au contraire même, car si tu lis bien l'explication de WAIT_OBJECT_0 le mutex indique qu'il n'est plus verouillé en basculant dans cet état. L'état signalé ça veut dire que le premier qui fait un WaitFor dessus en deviendra le propriétaire. Donc après un WAIT_ABANDONED, tu deviens le propriétaire et le mutex bascule en état non signalé afin que personne ne puisse en acquérir la propriété dès qu'il appel WaitFor.

[Aurelien.Regat-Barrel]

autre probleme
j'ai fais ma classe mutex(char * name)
d'ou herite la classe "driver de peripherique"

la blague est que pour chaque instance de driver, je recrée un handle de mutex. Donc si j'ai dans le meme process trois threads qui communiquent avec le peripherique, je me retrouve avec

3 threads
3 drivers
3 handles sur le meme mutex

il me semble que l'on peut faire la meme chose avec un seul handle, mais la il faudrait que je l'initialise ailleurs (en debut de programme) et que je le relache ailleurs en fin. Avec ma solution les handle de mutex naissent quand j'instancie mon driver et meurrent en tant qu'objet automatique.

Il te faut un seul handle de mutex, idem le driver. Ton mutex ne doit être utilisé qu'à un seul endroit : pour utiliser le driver. Le même mutex doit être utilisé par tout le monde biensûr.
Tu devrais plutot faire une classe moniteur sur ton driver qu'une classe mutex. Ton moniteur en interne utilise un mutex. C'est une classe singleton (voir FAQ C++) qu'on utiliserait un peu comme ç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
16
17
18
19
20
21
22
23
24
void thread1()
{
    DriverManager dm;
    dm.UseDriver1();
    dm.UseDriver2();
    dm.UseDriver3();
}

void thread2()
{
    DriverManager dm;
    dm.UseDriver1();
    dm.UseDriver2();
    dm.UseDriver3();
}

void thread3()
{
    DriverManager dm;
    dm.UseDriver1();
    dm.UseDriver2();
    dm.UseDriver3();
}

DriverManager fait un WaitForSingleObject sur un mutex dans son constructeur, et un ReleaseMutex dans son destructeur.

[buzzz]

oui ben justement la j'ai une boulette

car comme tu l'as ecrit dans ton autre post
pour la classe singleton il va falloir faire un test
pour savoir si l on a deja cree le mutex (le handle)

et en multithread comparaisons
=> je peux creer deux handles et ne gardez l'adresse du dernier

donc je suppose ouvrir un critical section
ou faire l'initialisation au depart du programme

j'ai du mal a comprendre si ce n'est pas bien au sens ou c'est faux
d'avoir plusieurs handle (il me semble pas) ou si ca mange trop de ressources (la je peux comprendre)

[Aurelien.Regat-Barrel]

Faut distinguer la création du mutex de son utilisation. Tu peux créer le mutex dans le main() avant la création des threads.
Après je comprends pas ton histoire de plusieurs handles. Une fois que tu as créé ton handle sur ton mutex, il est utilisable par tous tes threads. Pourquoi tu veux en créer d'autres ?
Il me semble t'avoir donné du code plus haut où je crée le mutex, puis les thread. Les thread lancés peuvent utiliser le mutex sans souci dès qu'ils sont lancés.

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 );

}

Au passage un handle c'est un identifiant. Je ne sais pas trop ce que tu veux dire par "avoir plusieurs handle".

Code :

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

1
2
3
4
HANDLE h1 = CreateMutex( ... );
HANDLE h2 = h1;
HANDLE h3 = h2;

Tu as 3 fois le même handle qui désigne le même mutex.

Code :

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

1
2
3
4
HANDLE h1 = CreateMutex( ... );
HANDLE h2 = CreateMutex( ... );
HANDLE h3 = CreateMutex( ... );

là tu as bien 3 handle différents, sur 3 mutex différents. Et c'est stupide car si chaque thread a son mutex, et ben y'aura aucune synchronisation vu que chacun utilise son propre mutex. A mois que ce soit 3 fois le même mutex nommé, mais c'est se compliquer la vie à mon avis. Vu que t'as une ressource unique, mieux vaut centraliser son utilisation en un seul endroit, au lieu de tout dupliquer/éparpiller. Je te le redit, à mon avis les thread n'ont même pas à gérer un mutex. C'est le rôle d'un objet moniteur qui centralise et controle l'accès à la ressourec unique. Les threads ne font qu'interragir avec le moniteur.

[buzzz]

ok bien compris !!!

effectivement le mutex nommé me permettait de creer le mutex dans le thread.