Discussion :

[buzzkaido]

[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 ?

[loufoque]

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.

[Charlemagne]

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 :

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

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

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

[buzzkaido]

Loufoque :

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é :

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

[loufoque]

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.

[buzzkaido]

Je viens de trouver ça dans la doc :

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)

[Charlemagne]

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.

[koala01]

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

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"

[buzzkaido]

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 !

[olive_le_malin]

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

[Charlemagne]

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?

[olive_le_malin]

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

[Charlemagne]

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)