[MT] Synchronisation de threads - S�maphore, Mutex ou SRWLock ?

[Message d�j� post� dans le forum Windows]

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 ?

Peut-�tre pourrais-tu faire un truc similaire � flock (fonction POSIX de verrou sur les entr�es/sorties) : un lecteur demande un verrou partag�, un �crivain demande un verrou exclusif.

Un verrou partag� peut �tre fourni s'il n'y a aucun verrou ou un verrou partag�.
Un verrou exclusif ne peut �tre fourni que s'il n'y a aucun verrou.

Avec trois valeurs d'un entier et l'op�ration atomique test and set �a doit se faire facilement.

Ton probl�me me fait penser � l'exemple d'utilisation des �v�nements dans la documentation de Visual.
En voici le contenu, tu peux peut-�tre t'en inspirer et transposer avec l'API multithread que tu utilises.
Certes la syntaxe de l'API Windows n'est pas des plus belles, mais on peut toujours tirer de cet exemple la substantifique moelle.
J'esp�re que �a peut t'aider.

Applications use event objects in a number of situations to notify a waiting thread of the occurrence of an event. For example, overlapped I/O operations on files, named pipes, and communications devices use an event object to signal their completion. For more information about the use of event objects in overlapped I/O operations, see Synchronization and Overlapped Input and Output.

In the following example, an application uses event objects to prevent several threads from reading from a shared memory buffer while a master thread is writing to that buffer. First, the master thread uses the CreateEvent function to create a manual-reset event object. The master thread sets the event object to nonsignaled when it is writing to the buffer and then resets the object to signaled when it has finished writing. Then it creates several reader threads and an auto-reset event object for each thread. Each reader thread sets its event object to signaled when it is not reading from the buffer.

Code:

---

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 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52

#define NUMTHREADS 4   HANDLE hGlobalWriteEvent;   void CreateEventsAndThreads(void) { HANDLE hReadEvents[NUMTHREADS], hThread; DWORD i, IDThread;   // Create a manual-reset event object. The master thread sets // this to nonsignaled when it writes to the shared buffer.   hGlobalWriteEvent = CreateEvent( NULL, // no security attributes TRUE, // manual-reset event TRUE, // initial state is signaled "WriteEvent" // object name );   if (hGlobalWriteEvent == NULL) { // error exit }   // Create multiple threads and an auto-reset event object // for each thread. Each thread sets its event object to // signaled when it is not reading from the shared buffer.   for(i = 1; i <= NUMTHREADS; i++) { // Create the auto-reset event. hReadEvents[i] = CreateEvent( NULL, // no security attributes FALSE, // auto-reset event TRUE, // initial state is signaled NULL); // object not named   if (hReadEvents[i] == NULL) { // Error exit. }   hThread = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE) ThreadFunction, &hReadEvents[i], // pass event handle 0, &IDThread); if (hThread == NULL) { // Error exit. } } }

---

Before the master thread writes to the shared buffer, it uses the ResetEvent function to set the state of hGlobalWriteEvent (an application-defined global variable) to nonsignaled. This blocks the reader threads from starting a read operation. The master then uses the WaitForMultipleObjects function to wait for all reader threads to finish any current read operations. When WaitForMultipleObjects returns, the master thread can safely write to the buffer. After it has finished, it sets hGlobalWriteEvent and all the reader-thread events to signaled, enabling the reader threads to resume their read operations.

Code:

---

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 34 35 36 37 38 39 40 41 42 43 44 45 46

VOID WriteToBuffer(VOID) { DWORD dwWaitResult, i;   // Reset hGlobalWriteEvent to nonsignaled, to block readers.   if (! ResetEvent(hGlobalWriteEvent) ) { // Error exit. }   // Wait for all reading threads to finish reading.   dwWaitResult = WaitForMultipleObjects( NUMTHREADS, // number of handles in array hReadEvents, // array of read-event handles TRUE, // wait until all are signaled INFINITE); // indefinite wait   switch (dwWaitResult) { // All read-event objects were signaled. case WAIT_OBJECT_0: // Write to the shared buffer. break;   // An error occurred. default: printf("Wait error: %d\n", GetLastError()); ExitProcess(0); }   // Set hGlobalWriteEvent to signaled.   if (! SetEvent(hGlobalWriteEvent) ) { // Error exit. }   // Set all read events to signaled. for(i = 1; i <= NUMTHREADS; i++) if (! SetEvent(hReadEvents[i]) ) { // Error exit. } }

---

Before starting a read operation, each reader thread uses WaitForMultipleObjects to wait for the application-defined global variable hGlobalWriteEvent and its own read event to be signaled. When WaitForMultipleObjects returns, the reader thread's auto-reset event has been reset to nonsignaled. This blocks the master thread from writing to the buffer until the reader thread uses the SetEvent function to set the event's state back to signaled.

Code:

---

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 34

VOID ThreadFunction(LPVOID lpParam) { DWORD dwWaitResult; HANDLE hEvents[2];   hEvents[0] = *(HANDLE*)lpParam; // thread's read event hEvents[1] = hGlobalWriteEvent;   dwWaitResult = WaitForMultipleObjects( 2, // number of handles in array hEvents, // array of event handles TRUE, // wait till all are signaled INFINITE); // indefinite wait   switch (dwWaitResult) { // Both event objects were signaled. case WAIT_OBJECT_0: // Read from the shared buffer. break;   // An error occurred. default: printf("Wait error: %d\n", GetLastError()); ExitThread(0); }   // Set the read event to signaled.   if (! SetEvent(hEvents[0]) ) { // Error exit. } }

---

Loufoque :

Citation:

---

Un verrou partag� peut �tre fourni s'il n'y a aucun verrou ou un verrou partag�.
Un verrou exclusif ne peut �tre fourni que s'il n'y a aucun verrou.

---

Justement, le SRWLock a l'air d'�tre fait pour �a...

En fait, je me demande surtout si le thread qui attend d'acqu�rir le verrou en mode exclusif (le thread qui �crit) ne risque pas d'attendre ind�finiment du fait que les lectures (et donc le acquisitions du verrou en mode partag�) vont se faire tres souvent et � plusieurs en m�me temps...

Dans la doc de l'API windows, il est precis� :

Citation:

---

There is no guarantee about the order in which threads that request ownership will be granted ownership; SRW locks are neither fair nor FIFO.

---

Donc pas de priorit� � l'un ou � l'autre...

Certaines biblioth�ques qui fournissent ce genre de mutex (comme boost.thread par exemple) permettent de choisir comment cela doit �tre ordonnanc� : FIFO, priorit�s ou non d�fini.

Je viens de trouver �a dans la doc :

Citation:

---

When /MT, /MTd, /MD, or /MDd is used, the following thread-safety rules are in effect:

The container classes are vector, deque, list, queue, stack , priority_queue, valarray, map, multimap, set, multiset, basic_string, bitset.

For reads to the same object, the object is thread safe for reading in the following scenarios:

- From one thread at a time when no writers on other threads.
- From many threads at a time when no writers on other threads.

For writes to the same object, the object is thread safe for writing from one thread when no readers on other threads

For reads to different objects of the same class, the object is thread safe for reading in the following scenarios:

- From one thread at a time.
- From one thread at a time when no writers on other threads.
- From many threads at a time.
- From many threads at a time when no writers on other threads.

For writes to different objects of the same class, the object is thread safe for writing in the following scenarios:

- From one thread when no readers on other threads.
- From many threads.

For example, given objects A and B of the same class, it is safe if object A is being written in thread 1 and B is being read in thread 2.

---

Est-ce que cela signifie bien que si mes objets sont stock�s dans des vecteurs (c'est le cas) je peut lire et ecrire dedans sans me pr�occuper des threads ?

(je compile avec /MT)

Non
Grosso modo, qu'on ne peut que soit lire soit �crire � partir de plusieurs threads, mais pas les 2 � la fois.
(Sinon l'exemple de la doc de Visual sit� plus haut n'aurait plus de sens)
Y'a des biblioth�ques sp�ciales qui impl�mentent des containers s�curis�s (et un peu plus lents) pour le multi-threading. Je sais par exemple que la biblioth�que payante TBB d'Intel le permet.

Salut,

Je m'interroge sur un point...

D'accord, tu consid�re qu'un des threads lecture seule doit avoir priorit� sur les autres... Soit, c'est ton droit le plus stricte... Mais...

Dans quelle mesure te parrait-il sens� qu'il ai la priorit� de lecture, si les donn�es qu'il lit ne sont, potentiellement, plus � jour :question:

Selon moi, mais ce n'est ici qu'un avis personnel, priorit� doit etre donn�e � la mise � jour des informations, donc, � l'�criture...

De cette mani�re, les threads qui demanderont l'acces en lecture auront bien plus de chances de disposer, quand leur tour de "jouer" arrive, des "derni�res nouvelles" ;)

Charlemagne :

Merci pour les pr�cisions !

koala01 :

Effectivement, vu comme �a....
De toute maniere, avec les SRWLock, on ne peut prevoir la priorit�, je vais donc faire une petite serie de tests pour voir comme que �a marche...

Merci !

salut,
je sais pas si c'est pertinent par rapport � ton projet, mais perso j'utilise les CriticalSection pour les acc�s � des ressources partag�es en R/W par X threads ...

Je suis pas s�r du tout d'un truc sur les sections critiques de windows.
J'ai l'impression qu'elles s'apparentent � un SpinMutex, et que donc le processus est occup� pendant l'attente de la lib�ration. Ce qui ne justifierait leur utilisation que pour des attentes tr�s courtes.
Quelqu'un peut confirmer ou infirmer?

ton thread est bloqu� sur le Lock()
mais on peut tester l'acc�s � la ressource (lock� ou non) en utilisant les MFC CSingleLock avec CCriticalSection

Je comprends pas bien ta r�ponse. Le processeur est t-il occup� ou non � attendre qu'une section critique soit lib�r�e?
(Je connais pas les MFC, j'utilise l'API du SDK)
Ben s�r qu'on peut tester la disponibilit�, mais en g�n�ral on veut attendre l'acquisition (tel un mutex)