Discussion :

[saad.hessane]

Bonjour tout le monde,
Je m'amuse avec un petit programme de test à l'apprentissage de la programmation multi-threader en C++ sous Windows. J'ai lu un peu la doc MSDN à ce sujet, et j'ai écrit un petit programme de test avec une fonction qui crée un fichier et écrit dedans (la fonction threadWrite), et un main qui crée des threads exécutant cette fonction.

Code C++ :

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
53
54
55
56
 
 
#include <Windows.h>
 
#include <iostream>
#include <fstream>
#include <sstream>
 
#define THREAD_NUMBER 10000
 
 
using namespace std;
 
DWORD WINAPI threadWrite( LPVOID lpParam ){
  int tNumber = 0;
  stringstream nameFile;
 
  tNumber = *((int*)lpParam);
  nameFile << "Test" << tNumber << ".txt";
 
  ofstream fichier(nameFile.str(), ios::out | ios::trunc);
 
  if(fichier){
    for(int i=0; i<5 ; i++)
      fichier << "Thread" << tNumber << endl;
 
    fichier.close();
  }
  else
    return 1;
 
  return 0;
}
 
 
 
int main(void){
  int tCount[THREAD_NUMBER];
  HANDLE threads[THREAD_NUMBER];
 
  cout << "debut" << endl;
 
  for( int i=0; i<THREAD_NUMBER ; i++ )
    tCount[i] = i+1;;
 
  for( int i=0 ; i<THREAD_NUMBER; i++ )
    threads[i] = CreateThread(NULL, 0, threadWrite, &tCount[i], 0, NULL);
 
  WaitForMultipleObjects( THREAD_NUMBER, threads, TRUE, INFINITE );
  cout << "fin" << endl;
 
  for( int i=0 ; i<THREAD_NUMBER; i++ )
    CloseHandle(threads[i]);
 
  return EXIT_SUCCESS;
}

Je test le programme avec différentes valeurs de THREAD_NUMBER, des fois à 100, 1000 puis 10000. Pour 100 et 1000 le programme semble bien marché, il y a bien 100 ou 1000 fichiers de créé avec les valeurs écrites dans chaque fichier.
Pour 10000 par contre le comportement du programme devient non déterministe d'une exécution à l'autre : des fois 2000 fichiers sont créés, d'autres 5000...
Mon code ne comporte aucune ressource partagée. Donc j'estime qu'il ne n'y a pas de problème de verrouillage nécessitant l'utilisation de sémaphore.
Je penche plutôt pour une limitation de nombre de threads créés simultanément. Ou alors le nombre de fichiers ouvert simultanément. Ou une autre limitation dont je n'aurais pas connaissance.
Merci de m'aider à résoudre mon problème.

[BlueMonkey]

Bonsoir,

A chaque thread créé, de la mémoire est alloué. (chaque thread à sa propre pile).
Lorsqu'on créé un thread avec : CreateThread(), le second paramètre
indique la taille qu'on réserve pour sa pile. En indiquant 0, on prend la taille par défaut.
soit 1Mo par thread. Donc pour 10 000 threads ... 9,77 Go de RAM ...
source >>ici<<

En changeant la taille par défaut, tu devrais être capable d'atteindre les 10000 threads.
Mon avis perso, dépasser la centaine de thread simultané pour un processus n'a pas vraiment de sens.
Et 10 000 threads qui tente d'écrire en // sur le disque dur ...

[saad.hessane]

Merci pour ta réponse BlueMonkey. Mais s'il y a beaucoup de mémoire qui est allouée, le programme va seulement ramer. Qu'est ce qui explique le fait que les fichiers ne soit pas écrit?
Je suis d'accord avec toi à propos des 10000 threads. T'inquiète pas c'est juste pour apprendre comme je t'ai dit. J'essaie de connaitre un peu les limites et les subtilités d'utilisation des threads sous Windows.
Merci encore une fois.

[Ekleog]

En général, il y a une limite au nombre de threads par processus.

Mais je ne la connais pas sous windows.

[BlueMonkey]

Mais s'il y a beaucoup de mémoire qui est allouée, le programme va seulement ramer.

On parle tout de même de presque 10 Go de RAM. Suivant le type de poste (32 ou 64 bits) ,
la quantité de RAM physique, la configuration de la mémoire virtuelle les conséquences
iront plus loin que juste ralentir le PC. (ex : sur une machine 32 bits, il n'est pas possible d'adresser
plus de 2^32 adresses mémoire, soit moins de 4Go de RAM )

Sur cette page >> ici <<, Mark Russinovich a été capable de créer 56000 thread sur une machine 64 bits.

[saad.hessane]

Suivant le type de poste (32 ou 64 bits) , la quantité de RAM physique, la configuration de la mémoire virtuelle les conséquences
iront plus loin que juste ralentir le PC. (ex : sur une machine 32 bits, il n'est pas possible d'adresser
plus de 2^32 adresses mémoire, soit moins de 4Go de RAM )

Ok.
Je repose ma question autrement.
Comment savoir si un thread a bien été créer, et être sûre qu'il exécutera son code comme il faut. J'ai changé mon exemple précedent en ajoutant un test sur le retour de la fonction CreateThread. Mais il semblerai que tous les threads soit créés (retour de la fonction non NULL), alors que seul 5000 threads arrive à créer un fichier.
Merci.

[Ekleog]

Peut-être faire renvoyer une valeur par les threads à leur fin, comme par exemple dans un void* qui serait passé en paramètre ? (C'est la généralité, je ne connais pas l'API threads windows.)

Sinon, est-ce qu'il n'y aurait pas de limite de 5000 files / dossier avec ton système de fichiers ? Parce que 5000 tout rond, ça semble étrange ...

[BlueMonkey]

Doc GCC libstdc++ § Defaults

So, if your platform's C library is threadsafe, then your fstream I/O operations will be threadsafe at the lowest level. For higher-level operations, such as manipulating the data contained in the stream formatting classes (e.g., setting up callbacks inside an std::ofstream), you need to guard such accesses like any other critical shared resource.

En d'autre terme, la classe ofstream de la librairie standard n'est pas ThreatSafe.
Il est probable que les opérations d'écriture dans les fichiers plantent à cause de ça.
Pour effectuer des écritures de fichiers via des threat :
- soit utiliser des méthodes de verrous pour éviter des utilisations de cette classe en //.
- soit utiliser les fonction de la libc

The system's libc is itself thread-safe,

§Thread Safety )

Pour tester le bon déroulement des thread :
- passer un pointeur sur un résultat comme indiqué par Equinoxe_
(attention toute fois à se protéger contre la concurrence lecture / écriture.
- ExitThread et GetExitCodeThread pour tester un code de fin d'exécution.
- utilisation de PostMessage / PeekMessage entre thread (pour échange et synchronisation) voir >>ici<<

[saad.hessane]

Sinon, est-ce qu'il n'y aurait pas de limite de 5000 files / dossier avec ton système de fichiers ? Parce que 5000 tout rond, ça semble étrange ...

En fait le programme devient totalement hazardeux en passant à 10000 thread. des fois il crée dans les 5000 fichiers, d'autres dans les 3000, des fois 6000... (c'est des ordres de grandeurs, le nombre de fichiers n'est pas rond).

En d'autre terme, la classe ofstream de la librairie standard n'est pas ThreatSafe...

Je pense que tout est dit. Merci à vous deux.

[Ekleog]

Non.

En effet, je viens de lire la page du lien. C'est la manipulation des informations internes du ofstream qui n'est pas thread-safe.
Du coup, si tu utilises un ofstream par thread, alors ça ne devrait pas poser de problème.

Si tu veux être certain, utilises la libc ; et donc fopen & co. Au moins, elle, elle est thread-safe (enfin, normalement ...).

[therwald]

Le PC peut ramer si on passe la quantité de RAM physiquement présente...mais si on consomme plus de mémoire que la taille de la mémoire virtuelle (qui est aussi plafonnée, et peut être plus petite que la limite d'adressage), on aura des échecs d'allocation...il me semble que ça peut parfaitement tuer une thread en cours de route.