[C++] threads et portabilité

Version imprimable

03/03/2006, 18h01
b4u

[C++] threads et portabilité

Bonsoir,

j'ai entendu dire que la création d'un thread est une opération relativement lente, or j'ai besoin du plus de vitesse possible pendant le court déroulement de mon thread (qui occupe la partie dialogue avec un client dans une application serveur). J'ai donc pensé a créer un "pool" de threads en début de programme, et déclencher l'exécution d'un d'eux lorsque le moment est venu. Sous windows, la fonction CreateThread() me permet de spécifier le flag CREATE_SUSPEND, mais je n'ai pas trouvé d'équivalent unix (pthread_create()). Y a-t-il une méthode portable pour arriver à mes fins?
Merci d'avance :)
04/03/2006, 01h23
Luc Hermitte

Utiliser une bibliothèque portable ? ACE, boost, QT, ... ?
04/03/2006, 01h49
loufoque

les threads posix en C sont aussi relativement portables.
04/03/2006, 09h22
reggae

Portable...
http://www.boost.org/doc/html/threads.html
04/03/2006, 11h44
b4u

Je comptais m'en sortir "nativement" avec un truc comme
#ifdef WIN32
CreateThread()
#else
pthread_create()
#endif
Mais au niveau implémentation, comment repousser l'execution du thread (sachant qu'il est déa créé)? Ou alors est-ce qu'il existe une fonction, que j'appelerais en premier dans mon thread, qui me permettrait de le mettre en attente jusqu'à ce que je décide (à partir du thread principal) de stoper cette attente et passer à la suite?
04/03/2006, 19h35
Alp

Et en encapsulant la gestion des thread dans une class, et tu fais ça soit par templates soit par héritage pour avoir une certaine abstraction ... Ainsi dans ton code t'aurais juste à mettre un seul couple de #ifdef et #else (et #endif), celui qui créérait la variable, qui aurait le même nom, mais un type légèrement différent.
04/03/2006, 19h54
b4u

merci :)
je vais implémenter une classe abstraite pour gérer tout ca.
05/03/2006, 19h55
Luc Hermitte

:?
Je ne comprendrais jamais l'intérêt de recoder (pour une vraie application) des choses que d'autres ont déjà codé, blindé et validé sérieusement.
05/03/2006, 20h03
b4u

ça m'est imposé de ne pas utiliser de librairie (hormis la STL) et de classes extérieures au projet.
05/03/2006, 20h19
Luc Hermitte

:? n'hésite pas pour autant à consulter articles et bibliothèques qui font déjà cela.
05/03/2006, 20h27
b4u

J'avoue que dans un contexte orienté objet c'est idiot de devoir réinventer la roue, mais bon c'est purement scolaire :)
J'essaye de m'inspirer au maximum d'interfaces déja disponibles... et même si au final mon truc sera mal designé, ce ne sera pas une classe que je compte réutiliser dans d'autres projets.
05/03/2006, 20h30
Luc Hermitte

Je dis surtout ça par rapport aux différents problèmes, issus des particularités de chacun, que tu rencontreras et qui sont "connus" (des spécialistes)
05/03/2006, 21h14
loufoque

Citation:

ça m'est imposé de ne pas utiliser de librairie (hormis la STL) et de classes extérieures au projet.

Parce que l'api win32 ou posix ce sont pas des bibliothèques peut-être ?
05/03/2006, 21h35
Luc Hermitte

Peut-être des "contraintes" projet vendues au client : ce qui est natif au système plus telle ou telle lib ?
05/03/2006, 23h14
b4u

voila un extrait du sujet (c'est un projet d'études):

Citation:

# Third Party libraries are not allowed, with the exception of an XML Library,
# Using the C++ STL is strongly advised, if not mandatory,
06/03/2006, 09h38
Médinoc

Et donc, les pthreads ne sont pas considérés comme une third-party library ?
S'ils le sont, tu peux déjà abandonner le projet, puisqu'il n'y a rien pour les threads en C++ standard.

Quelles sont les circonstances du projet? Je suppose que c'est supposé tourner sur un unixoïde ?