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)