[C++] threads et portabilité

**b4u** · 03/03/2006, 18h01

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

**Luc Hermitte** · 04/03/2006, 01h23

Utiliser une bibliothèque portable ? ACE, boost, QT, ... ?

**loufoque** · 04/03/2006, 01h49

les threads posix en C sont aussi relativement portables.

**reggae** · 04/03/2006, 09h22

Portable...
http://www.boost.org/doc/html/threads.html

**b4u** · 04/03/2006, 11h44

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?

**Alp** · 04/03/2006, 19h35

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.

**b4u** · 04/03/2006, 19h54

merci

je vais implémenter une classe abstraite pour gérer tout ca.

**Luc Hermitte** · 05/03/2006, 19h55

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.

**b4u** · 05/03/2006, 20h03

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

**Luc Hermitte** · 05/03/2006, 20h19

n'hésite pas pour autant à consulter articles et bibliothèques qui font déjà cela.

**b4u** · 05/03/2006, 20h27

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.

**Luc Hermitte** · 05/03/2006, 20h30

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)

**loufoque** · 05/03/2006, 21h14

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

**Luc Hermitte** · 05/03/2006, 21h35

Peut-être des "contraintes" projet vendues au client : ce qui est natif au système plus telle ou telle lib ?

**b4u** · 05/03/2006, 23h14

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

# Third Party libraries are not allowed, with the exception of an XML Library,
# Using the C++ STL is strongly advised, if not mandatory,

**Médinoc** · 06/03/2006, 09h38

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 ?

[C++] threads et portabilité

C++

Discussions similaires

Partager

Partager