Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous

Identifiant
Mot de passe

Mot de passe oublié ?

Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Quelles API/bibliothèques pour le développement multithread en C++ ?

Le 18 novembre 2009 à 10:38, par 3DArchi

16 commentaires

0PARTAGES

Voter pour

1

Voter contre

0

Quelles API/bibliothèques pour le développement multithread ?

Boost.Thread		48 %
API du framework I.H.M. de mon projet (MFC, Qt, wxWidgets)		29 %
C++11 (std::thread)		24 %
API du système (Win32 par exemple)		20 %
Thread POSIX		20 %
Autre (préciser)		8 %
ACE		5 %
POCO		5 %
just::thread		4 %

Voter 75 votants

Bonjour,
Il existe beaucoup d'options pour faire du multithread : API spécifique de l'O.S., bibliothèques multiplateformes, abstractions de plus haut niveau, etc.
Qu'utilisez-vous pour vos développements concurrents et pourquoi ? Quels sont les limites que vous trouvez et qu'aimeriez vous avoir comme autres services ?

Ce sondage porte sur leur utilisation dans le cadre de la programmation concurrente, les objectifs principaux étant la réactivité et l'isolation (agents asynchrone => IHM non bloquantes, tâche dédié traitements, etc..). Pour la programmation multithread dans un objectif de supporter une montée en charge (programmation //), voir ce sondage.

Une erreur dans cette actualité ? Signalez-nous-la !

Votre nom : Votre e-mail :

Décrivez l'erreur que vous souhaitez porter à notre connaissance :

16 commentaires

Commenter Signaler un problème

Inactif

Le 19/11/2009 à 17:30

Personnellement, j'utilise toujours l'API native quand l'outil n'est pas prévu / conçu pour être portable (je pense notamment aux outils dédiés à un système donné).

Toutefois, dans le cas d'un projet portable, j'ai pu utiliser ACE, ICE et POCO. Boost ne fait pas partie du lot car non supporté sur certaines de mes plate-formes. Dans ce genre de cas, j'ai quand même nettement tendance à préférer abstraire l'intégralité des fonctions utilisées de l'OS et non pas juste la partie MT, d'où mon choix de librairies d'abstraction complètes d'un OS.

Au final :

API natives : Win32 nettement supérieur à pthread sur le plan pratique / mnémotechnique. Toutefois, j'ai toujours déploré l'absence de locks lecteur/rédacteur sous Win32 (corrigé depuis Vista, mais pas sur les anciennes plate-formes), alors que cela existe sur pthread : cela pose parfois quelques soucis, amenant alors à utiliser une librairie générale pour le multi plate-forme au lieu d'un simple wrapper maison.
ACE : OK, c'est puissant et ça supporte des cibles peu courantes. Toutefois, l'API n'est pas claire, la doc non plus et il y a quelques comportements étranges.
POCO : Très puissant, très bien documenté, très pratique. Seul inconvénient : relativement peu de cibles supportées par rapport à ACE.
ICE : Très léger sur le plan abstraction d'OS, c'est limité aux éléments essentiels à la gestion des threads / sockets. Toutefois, si cela suffit au besoin, c'est aussi pratique à utiliser que POCO.
Le couple ICE (pour la communication) plus POCO (pour l'abstraction d'OS) est assez royal à utiliser.

A tester un de ces jours :

OpenMP, notamment la compatibilité entre VS/Win32 et GCC/Linux (avec sources identiques, bien entendu).
Trouver un pendant à PThreadWin32, qui wrapperait l'API Win32 sur Linux/PThreads, de façon à simplifier certains portages d'anciennes applications.

Voter pour

2

Voter contre

0

Le 18/11/2009 à 15:53

je développe pour des plates-formes plutot multiples (sous-entendu non supportées par boost) donc j'utilise l'API systeme (Win32 sous windows, pthreads sous linux/mac/solaris, spécifique sur console/iphone)

Voter pour

1

Voter contre

0

Rédacteur/Modérateur

Le 18/11/2009 à 17:59

J'ai plus voté pour ce que j'utiliserais sur un nouveau projet que pour ce que j'utilise dans du code historique. Dans "Autre", j'ai pensé aux TBB (mais aussi peut-être à la bibliothèque avec un positionnement semblable de Microsoft TPL)

Voter pour

1

Voter contre

0

Expert éminent sénior

Le 19/11/2009 à 10:36

J'ai voté pour plein de choses.
Aujourd'hui : ACE
A tester : ICE
Demain: la partie threads de C++0x, à défaut ceux de boost, à condition qu'ils viennent à supporter les tâches qui communiquent via queues de messages (ACE_Task, agents de VC10 -- comment faire du MT sérieusement sans ça ?). Accessoirement, just::thread me semble implémenter des mutex hiérarchiques (cf l'article d'Herb Sutter à ce sujet), et mérite donc que l'on s'y attarde.

Voter pour

1

Voter contre

0

Inactif

Le 19/11/2009 à 14:36

(Je ne connais pas ACE ou POCO)
J'utilise l'API Windows, Mac et Pthread (Posix) dont je me suis fait des wrappers à la façon TBB (en moins complet).
Je préfère de loin l'API pthread à l'API Windows, mais ça oblige d'installer la lib pthreads_win32 (qui ne fait que wrapper l'API Windows).

J'ai voté "autre" en pensant à OpenMP: (c'est plus orienté calcul pur et dur pour paralléliser les boucles), je n'aime pas la syntaxe trop C. Ceci dit c'est facile, efficace et intégré à tout bon compilateur

J'ai jamais utilisé TBB, c'est tout de même le concept que je préfère, car ça ressemble à la STL, même si je trouve qu'il y a des lourdeurs.

Je trouve que Boost ne fait pas grand chose, si ce n'est wrapper l'API Windows, Mac ou pthread.

Quand le C++0x sera là, je m'y mettrai, ça fera plaisir de ne plus avoir 36 couches de wrappers...

PS: Je commence à toucher à OpenCL, c'est une interface C quand même compliquée (je me suis fait des wrappers...), mais c'est ce qui me parraît encore être le plus simple et le plus portable pour la programmation GPU.

Voter pour

1

Voter contre

0

Membre régulier

Le 08/12/2011 à 14:24

openmp ca marche bien. faut pas l'oublier dans le sondage. sur mac faut avoir gcc 4.2 donc OSx10.6 mini. sous win ca marche bien aussi, a part un joli petit piège de l'implementation de microsoft qui leak les threads créés si ta boucle openmp ne part pas du main thread.

Voter pour

1

Voter contre

0

Membre habitué

Le 18/11/2009 à 10:49

Je préfére coder moi même ma librairie de thread basé sur les API système comme ca le systeme est adapté à mes besoins et il n'y a rien de superflu. Les autres librairies étant concut pour être adapté à tous, je pense qu'elles sont un peu trop lourde pour quelque chose supposé être très rapide.
Les limites ? Le temps que ca prends à coder et les problèmes de thread non géré nativement (dead locks...) qu'il faut donc gérer soit même.

Voter pour

1

Voter contre

1

Emmanuel Deloget

Expert confirmé

Le 08/12/2011 à 14:55

J'ai voté C++11 / just::thread (enfin, std::thread maintenant), parce que ça me semble logique (et que la librairie est particulièrement bien pensée).

Voter pour

0

Voter contre

0

Expert éminent sénior

Le 08/12/2011 à 15:11

just::thread c'est plus que le standard.
Cette implémentation commerciale offre des facilités supplémentaires pour le debuggage p.ex.

Sinon, il faudrait peut-être distinguer les libs orientés concurrences de celles orientées parallélisme -- et les hybrides, car il y en a toujours.
Il est difficile de laquelle est mieux quand en fait toutes ne couvrent pas le même spectre de fonctionnalités, et sont en fait complémentaires.

Voter pour

0

Voter contre

0

Membre averti

Le 09/12/2011 à 8:27

Bonjour,

J'utilise beaucoup OpenMP. C'est facile à utiliser et c'est portable sur toutes les OS. Mais il n'est pas dans la liste !

Voter pour

0

Voter contre

0

Commenter Signaler un problème