Discussion :

[buzzkaido]

Bonjour,

Voila, j'ai une appli qui tourne avec plusieurs threads.

Ces differents threads se partagent des données.

Tous les threads accedent en lecture à ces données.
Tous les threads, sauf 1 qui est spécial accedent aussi en ecriture.

Voila mon probleme :

Le thread qui n'accedent qu'en lecture est le moteur principal du logiciel, il doit donc pouvoir s'executer le plus rapidement possible.

Les autres threads peuvent se permettre d'attendre un peu, c'est pas genant.

Je pense faire un truc du genre :

Acces en lecture :
- tant qu'une ecriture n'est pas en attente, on autorise la lecture.
- pendant la lecture, on interdit l'ecriture.

Acces en ecriture :
- on fait une demande d'ecriture (qui va bloquer les fonctions de lecture)
- on attend que toutes les lectures en cours soient terminées
- on ecrit
- on debloque la lecture

Vu que les performances du thread principal (que lecture) sont essentielles dans ce projet, quel objet de synchronisation utiliser ?

J'ai pensé à "Slim Reader/Writer (SRW) Locks" : http://msdn2.microsoft.com/en-us/library/aa904937.aspx

D'après la doc, c'est le plus rapide, mais je ne sais pas trop comment l'utiliser...

Des idées ?

[Médinoc]

Normalement, les SRW locks sont l'idéal.
Mais si tu veux que ton application puisse tourner ailleurs que sous Vista, tu oublies.

J'ai bien peur que tu doives implémenter ton propre verrou lecteurs/écrivain (sans doute à base de sémaphores et d'events), ou peut-être un truc dont l'écriture serait plus atomique, avec un double-buffer en prime...

Enfin, sans le SRWLock, ça ne va pas être facile.

[buzzkaido]

Les SRWLock c'est que sous Vista ?

Arg !

Tant pis, je vais me remonter les manches...

Merci !

[Aurelien.Regat-Barrel]

Jette un oeil aux sections critiques. Ce ne sont pas des objets kernel et sont donc plus performants (c'est fait pour la synchro inter-thread).
http://msdn2.microsoft.com/en-us/library/ms682530.aspx
En fonction de comment tu modifies la donnée, tu peux aussi jeter un oeil aux API InterlockedXXX:
http://msdn2.microsoft.com/en-us/library/ms684122.aspx
qui te garantissent une modif atomique d'une variable.

[NiamorH]

Rien n'indique qu'une section critique va permettre a la tache principale d'acceder a la zone critique en priorité si ? Ou alors voila comment je penserais faire a priori :

Code :

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

1
2
3
SecCritique1
SecCritique2
Evenement1

Pour les threads secondaires :

Code :

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

1
2
3
4
5
6
7
8
SecCritique1.entrer();
Evenement1.attendre();
SecCritique2.entrer();

(...)

SecCritique2.sortir();
SecCritique1.sortir();

Pour la tache principale :

Code :

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

1
2
3
4
5
6
7
Evenement1.designaler();
SecCritique2.entrer();
Evenement1.signaler();

(...)

SecCritique2.sortir();

[Médinoc]

En effet, les sections critiques ne donnent pas de priorité.
Je pensais plutôt à un truc du genre:

• Mutex/Section critique pour l'écrivain
• Événement "pas d'écrivain en attente", "désignalé" par l'aspirant écrivain, et nécessaire pour ouvrir en lecture (priorité à l'écrivain)
• Ensuite:
  
  • soit un comptage de lecteurs (InterlockedIncrement() etc.) et un événement "pas de lecteurs",
  • soit, si tu connais le nombre maximum de lecteurs, un sémaphore (et encore, si ça se trouve il n'est même pas nécessaire de connaitre effectivement ce nombre maximal, je ne me souviens plus trop de comment marchent les sémaphores).
• Edit: Plus peut-être une section critique pour les manipulations, ou un autre événement, enfin un truc supplémentaire pour éviter des "race conditions".

[Médinoc]

Un petit ensemble d'algos que j'espère à l'épreuve des "race conditions" :

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
Réservation en lecture:
	attend l'événement "pas d'écrivain" (priorité à l'écrivain)
	désignale l'événement "pas de lecteurs"
	ré-attend l'événement "pas d'écrivain"
	Incrémente nombre de lecteurs 
Libération en lecture:
	Décrémente le nombre de lecteurs
	Si ce nombre est nul, signale l'événement "pas de lecteurs"
	
Réservation En écriture:
	Réserve section critique/mutex "écriture"
	Désignale l'événement "pas d'écrivain"
	Faire:
		attend l'événement "pas de lecteurs"
	Tant que nombre de lecteurs n'est pas confirmé à zéro
Libération en écriture:
	Signale l'événement "pas d'écrivain"
	Relache section critique/mutex "écriture"

[buzzkaido]

Merci pour toutes ces réponses, je vais tester un peu tout ça, j'ai pas eu vraiment le temps ce week-end...

[NiamorH]

Ma solution n'est pas plus simple ?

[buzzkaido]

Plus simple, oui, mais j'ai besoin de performances optimales sur ce bout de code (c'est le coeur de mon logiciel, et il doit tourner en "quasi-temps-réél")

Donc j'aimerais éviter autant que possible de faire appel à plusieurs objets de synchro inter-thread.

En fait, j'ai modifié mon architecture, et ça me complique un poil le code par endroit, mais si je m'y prend bien, les threads n'auront pas besoin d'être synchronisés, car en utilisant plusieurs buffers, chaque thread ne fait que lire et ecrire sur son propre buffer.

J'y perds un peu en mémoire, mais pas des masses, et si mes tests sont bons j'y gagne presque 50% en temps de traitement !

Donc à moins d'avoir zappé quelque chose, je devrais m'en sortir comme ça...

En tout cas, ça ma permis d'apprendre à synchroniser des threads sous windows...

[Médinoc]

NiamorH: Ça dépend de ce que l'on veut.
Si l'on n'a pas besoin que les lecteurs puissent lire en même temps, on peut utiliser ta méthode (un verrou exclusif avec un membre prioritaire).

La mienne cherche à implémenter un verrou lecteurs/écrivain complet permettant que plusieurs lecteurs aient accès à la ressource en même temps, mais pour un petit projet ce n'est pas toujours nécessaire...

[NiamorH]

Ok j'ai mal lu le premier post, je pensais qu'un seul thread principal lisait et que tous les autres ecrivaient.

Par contre buzzkaido tu vas tout de même devoir synchroniser un peu pour passer les infos d'un thread à l'autre non ?
Ca depend de comment ton appli fonctionne et de ce que font les threads.