Bonjour
 
J'ai créé une application qui utilise les "pthread". J'aurais souhaité lancer beaucoup de threads mais il semble que sous Linux le nombre est limité (histoire de taille de "stack" ) alors qu'il m'en aurai fallu 1000 à 2000 maximum (ce qui ne pose pas de problèmes sous Windows).
 
Comme je n'ai pas trouvé de moyen pour passer outre cette limitation, j'ai essayé de coder différement mon programme pour que les process soient exécutés par paquets et non tout d'un coup, je pensais de cette façon passer outre le problème.
 
Et bien il semble que le problème est ailleurs car, même en exécutant les thread 1 par 1 (a chaque fois le thread se termine correctement avec pthread_exit()), au bout de 303 ~ 305 pthreads exécutés, j'ai toujours thread_create() qui me renvoi l'erreur 12.
 
En regardant avec "top -H -p PID" je n'ai d'ailleurs qu'un seul thread simultanné ce qui montre que ce n'est pas le problème, mon programme est tout simplement limité au nombre de création de threads
 
Si vous avez une idée pour m'aider pour résoudre ce problème ce n'est pas de refus

d'après vous c'est plutôt un problème de mon programme ou une limitation des pthread?

Je viens de compiller un programme simple pour créer des pthread en boucle jusqu'à ce que pthread_create() renvoi une erreur.
A chaque fois au 303ème thread il est impossible d'en créer de nouveaux.
Ce nombre est fixe que les threads restent actifs ou se terminent directement.
Que faire??

si tu sais ce que tu fais tu peux diminuer la taille des piles des threads. c'est une limitation 32bits.
 
Mais ça à l'air un peu bourrin ton truc. Tu ferais certainement mieux de travailler avec un pool de threads.
 
 
Q(uant à ta remarque sur windows, on y croit très fort, sans ordonnanceur O(1) ça doit pas consommer de ressources du tout)

303 * 8MB
 
CQFD

Pour ne pas avoir à modifier la pile des threads j'ai changé le fonctionnement de mon programme : les threads se ferment après leur exécution, c'est le processus père qui les recréés pour recommencer leur tâche.
 
Après avoir créé chaque thread je le détache avec "pthread_detach(thread_id)" pour que celui-ci libère les ressources automatiquement une fois terminé. Comme les threads se terminent rapidement ça laisse de la place aux autres ce qui me permet de créer le nombre de threads voulu.
 
Par contre cette méthode consomme largement plus de ressources CPU et est plus lente que si les threads restent actifs et n'ont pas besoin d'êtres réexécutés à chaque fois... pas top pour du pseudo TR

UN POOL DE THREADS
 
sinon ne detach pas, mais fasi préférentiellement des pthread_join

Aurais tu des liens avec des exemples simples de création de pool avec les pthread?
 
Je cherche actuellement mais rien de bien sympatique pour l'instant...

http://en.wikipedia.org/wiki/Thread_pool_pattern
 
la seule implémentation en C que je connaisse c'est dans la glib http://developer.gnome.org/doc/API [...] Pools.html

En dehors du fait que la creation de threads est affreusement lente sous win32, que le scheduler peine à la tache et que comme remarqué précedement il s'agit surtout d'une mauvaise approche, (je ne retrouve pas la discussion initiale) http://uwsg.iu.edu/hypermail/linux [...] /1581.html
 
 

C'est prouvé ou c'est encore une de ces légendes urbaines dont Internet se fait l'écho régulièrement ?
Windows XP Processeur Céléron M80 (un brouette,quoi...)

le code manquant est ici :  
 
http://mapage.noos.fr/emdel/clib.htm
Module CHRO
 
Ca donne :  

Ce qui ne me parait pas d'une lenteur extrême, création, et suppression synchrone incluse...

On peut bien prouver tout et son contraire avec un micro-benchmark idoine.
Mais justement sur lklm, dans la discussion initiale, il y avait des benchs comparatifs avec win32 sur les temps de creation. Le résultat étonnant étant que malgré le coté specifique des threads win32, c'était presque aussi couteux que de lancer un process plein et entier.
 
De toute façon cela reste très théorique puisqu'il est difficile de justifier la création dynamique de milliers de threads et que le scheduler de xp, par exemple, est particulierement attardé.

Encore une affirmation gratuite ?

Je sais que c'est très branché d'affirmer "Microsoft çaÿ le Mal" tel un mantra moderne, mais je préfère les faits avérés.

Sauf que j'ai sous le coude, entre autre, un rtrt ou tout est distribué (avec une friction minimale et mesurable, dynamiquement) depuis la création du kD-tree jusqu'au rendu, sur linux & windows, 32 et 64 bit.  
Il se trouve aussi que je l'ai écrit.  
J'ai donc une assez bonne idée des acrobaties qu'il faut faire pour arriver à un résultat décent (mesurable) par exemple sur une machine NUMA (= k8) tournant sous xp (ou plus précisement xp32 qui n'est que partiellement NUMA aware).  
 
Comme je ne crois pas que discuter de l'importance de la localité des données ou des details d'implémentation de méchanismes wait-free soit particulierement pertinent pour l'initiateur, et que d'autre part tu me cours un peu j'en resterais la.

Je n'avais pas remarqué ton edit, avec ce fabuleux bout de code. Je veux dire donner des leçons et tester le temps de création de threads sous win32 en utilisant les pthreads, il faut l'oser. Mais tu l'as fait.
 
Linux: 32760 pthread_create() in 960.367203 ms hence 29.32us/thread
xp: 32760 pthread_create() in 69842.000008 ms hence 2131.93us/thread
 
Soyons charitable et limitons un peu plus, parce que visiblement ça s'écroule...
 
xp: 10000 pthread_create() in 2118.000031 ms hence 211.80us/thread
 
Serait-il possible que ce magnifique noyau xp s'emmele un peu les pinceaux sur un bi-processeur ou l'exercice a, contrairement à ta machine, enfin un peu de chance de chatouiller le scheduler? On le dirait.
 
Note:
a) je n'ai pas la patience d'attendre les 100000 sur xp
b) il aurait fallu ammender le source pour dépasser les 32760 sur linux, et c'étais hors de propos
c) avant que de tirer des conclusions il vaut mieux savoir ce que l'on teste vraiment
d) les pthreads sur windows, dans un bench, c'te blague.
 

Pour ma part sous windows je n'avais pas utilisé les pthread, il y a peu être une différence de performances?
 
Il t'est possible de lancer 32760 pthread sous linux grace aux 64bits?

et pas que de les lancer

L'API win32/64 n'a absolument rien à voir avec la sémantique POSIX, donc oui on s'attendrait à ce qu'un bench de création de thread utilise le mode natif.
Mais mon argument initial était que d'une part que le coût de création d'un process ou d'une thread sont du même ordre (malgré la distinction claire) et d'autre part que le scheduler ne tient pas le choc.
 

Nan.
De toute façon, je ne saurais trop insister sur le fait, comme d'autres l'ont déjà fait, que cette approche est inneficace et injustifiable; elle rend la tache extremement difficile pour le scheduler contrairement à un pool synchronisé sur un machin (ou le systeme a une chance de prédire la charge).

Si mon approche est mauvaise, peu être pourrais-tu me dire comment tu aborderais le problème?
 
J'ai un réseau avec 1000 machines (ça va grandir). Je dois superviser en pseudo temps réel l'état réseau des machines, en leur envoyant un ping toutes les secondes depuis un seul poste sur lequel se trouve mon application.
 
Mon application est en Java, mais l'interface sous-traite la fonction ping à un programme en C pour un souci d'efficacité (le ping sous Java j'ai essayé mais je ne suis pas du tout convaincu). L'avantage d'avoir Java n'est pas la portabilité sur n'importe quelle machine car dans mon cas celle-ci sera soit sous Windows, soit sous Linux. Donc il me faut juste un programme en C pour les 2 plateformes.
 
Sous Windows j'y suis allé franco : je passe en paramètre au programme C les centaines d'adresses IP, le programme créé un thread (natif) pour chaque adresse, chaque thread effectue un Ping par l'intermédiaire de la bibliothèque M$ et écrit le résultat du ping, lu par l'interface Java qui l'affiche dans la GUI. Les threads restent vivants entre chaque ping, ils s'endorment seulement une seconde après chaque résultat.
Le programme C utilise même pas 1% de l'UC et les résultats sont pratiquement instantanés toutes les secondes comme prévu.  
 
Sous Linux j'ai essayé de procéder de la même manière. J'ai utilisé des pthread et, quand il n'arrive plus a en créer, il fait une petite pause avant de recommencer. Chaque thread forge son paquet à partir de l'adresse IP qui lui a été attribué. Une fois le résultat affiché, le thread meurt. Quand tous les thread "fils" sont morts, le thread pricipal les relance, ils vont donc recréer leur paquets pour faire un ping puis afficher leur résultat et de nouveau mourir...
En dehors d'utiliser plus d'UC, cette technique est bien plus lente et ne permet pas de réactualiser l'état de chaque machine toutes les secondes. C'est pourquoi il me faudrait procéder différemment, peu être avec un pool de thread comme énoncé précédemment?
 
J'espère avoir été clair et précis, merci de me donner votre opinion

fping
snmp
cacti
smokeping
NIH