IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Affichage des résultats du sondage: Quelles API/bibliothèques pour le développement multithread ?

Votants
75. Vous ne pouvez pas participer à ce sondage.
  • API du système (Win32 par exemple)

    15 20,00%
  • API du framework I.H.M. de mon projet (MFC, Qt, wxWidgets)

    22 29,33%
  • Thread POSIX

    15 20,00%
  • Boost.Thread

    36 48,00%
  • ACE

    4 5,33%
  • POCO

    4 5,33%
  • C++11 (std::thread)

    18 24,00%
  • just::thread

    3 4,00%
  • Autre (préciser)

    6 8,00%
Sondage à choix multiple
Threads & Processus C++ Discussion :

Quelle API pour la programmation concurrente ?


Sujet :

Threads & Processus C++

  1. #1
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2008
    Messages : 7 634
    Points : 13 007
    Points
    13 007
    Par défaut Quelle API pour la programmation concurrente ?
    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.

  2. #2
    Membre habitué
    Profil pro
    Inscrit en
    décembre 2008
    Messages
    124
    Détails du profil
    Informations personnelles :
    Âge : 28
    Localisation : France

    Informations forums :
    Inscription : décembre 2008
    Messages : 124
    Points : 148
    Points
    148
    Par défaut
    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.

  3. #3
    screetch
    Invité(e)
    Par défaut
    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)

  4. #4
    Rédacteur/Modérateur
    Avatar de JolyLoic
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2004
    Messages
    5 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2004
    Messages : 5 460
    Points : 16 185
    Points
    16 185
    Par défaut
    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)
    Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
    Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
    Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
    Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.

  5. #5
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2003
    Messages
    5 273
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : août 2003
    Messages : 5 273
    Points : 10 827
    Points
    10 827
    Par défaut
    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.
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...

  6. #6
    Inactif
    Profil pro
    Inscrit en
    mars 2004
    Messages
    743
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2004
    Messages : 743
    Points : 460
    Points
    460
    Par défaut
    (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.

  7. #7
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : octobre 2004
    Messages : 3 893
    Points : 4 758
    Points
    4 758
    Par défaut
    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.
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  8. #8
    Membre régulier
    Profil pro
    Inscrit en
    avril 2008
    Messages
    87
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : avril 2008
    Messages : 87
    Points : 111
    Points
    111
    Par défaut
    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.

  9. #9
    Expert confirmé

    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2007
    Messages
    1 895
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : septembre 2007
    Messages : 1 895
    Points : 4 542
    Points
    4 542
    Par défaut
    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).
    [FAQ des forums][FAQ Développement 2D, 3D et Jeux][Si vous ne savez pas ou vous en êtes...]
    Essayez d'écrire clairement (c'est à dire avec des mots français complets). SMS est votre ennemi.
    Evitez les arguments inutiles - DirectMachin vs. OpenTruc ou G++ vs. Café. C'est dépassé tout ça.
    Et si vous êtes sages, vous aurez peut être vous aussi la chance de passer à la télé. Ou pas.

    Ce site contient un forum d'entraide gratuit. Il ne s'use que si l'on ne s'en sert pas.

  10. #10
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2003
    Messages
    5 273
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : août 2003
    Messages : 5 273
    Points : 10 827
    Points
    10 827
    Par défaut
    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.
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...

  11. #11
    Membre averti Avatar de uriotcea
    Homme Profil pro
    Ingénieur / physicien
    Inscrit en
    septembre 2003
    Messages
    1 263
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur / physicien
    Secteur : Service public

    Informations forums :
    Inscription : septembre 2003
    Messages : 1 263
    Points : 432
    Points
    432
    Par défaut
    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 !

  12. #12
    Expert confirmé

    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2007
    Messages
    1 895
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : septembre 2007
    Messages : 1 895
    Points : 4 542
    Points
    4 542
    Par défaut
    Citation Envoyé par Luc Hermitte Voir le message
    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.
    C'est plus que le standard, certes, mais c'est une implémentation basée sur l'interface proposée par std::thread (le standard ne faisant que donner des requirements et une interface minimale, just::thread reste une implémentation de std::thread avec des extensions qui sont vendor-specific).
    [FAQ des forums][FAQ Développement 2D, 3D et Jeux][Si vous ne savez pas ou vous en êtes...]
    Essayez d'écrire clairement (c'est à dire avec des mots français complets). SMS est votre ennemi.
    Evitez les arguments inutiles - DirectMachin vs. OpenTruc ou G++ vs. Café. C'est dépassé tout ça.
    Et si vous êtes sages, vous aurez peut être vous aussi la chance de passer à la télé. Ou pas.

    Ce site contient un forum d'entraide gratuit. Il ne s'use que si l'on ne s'en sert pas.

  13. #13
    Membre éprouvé Avatar de oxyde356
    Homme Profil pro
    Ingénieur Recherche Imagerie
    Inscrit en
    février 2006
    Messages
    798
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur Recherche Imagerie

    Informations forums :
    Inscription : février 2006
    Messages : 798
    Points : 1 060
    Points
    1 060
    Par défaut
    J'ai voté boost::thread, simple et vraiment très pratique, de plus c'est plutôt complet niveau primitives de synchro, on fait ce qu'on veut avec de façon très intuitive et compatible linux/win. J'ai tellement l'impression de faire du marketing que je vais finir par dire : un acheter, un offert

  14. #14
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2008
    Messages : 7 634
    Points : 13 007
    Points
    13 007
    Par défaut
    Salut,
    Citation Envoyé par Luc Hermitte Voir le message
    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 me semble que le sondage ne propose que des libs orientés concurrences, non ?

  15. #15
    Expert éminent sénior
    Avatar de Luc Hermitte
    Homme Profil pro
    Développeur informatique
    Inscrit en
    août 2003
    Messages
    5 273
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : août 2003
    Messages : 5 273
    Points : 10 827
    Points
    10 827
    Par défaut
    Je trouve aussi.
    Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
    Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...

  16. #16
    Rédacteur
    Avatar de 3DArchi
    Profil pro
    Inscrit en
    juin 2008
    Messages
    7 634
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2008
    Messages : 7 634
    Points : 13 007
    Points
    13 007
    Par défaut
    Bonjour,

    Pour tout ceux qui sont frustrés de ne pouvoir proposer OpenMP, TBB, PPL ou CUDA, un nouveau sondage est ouvert ici : Quelle bibliothèque pour la programmation parallèle ?. Vous allez pouvoir voter pour LA bibliothèque qui assure vos performances

  17. #17
    Membre expert
    Avatar de Klaim
    Homme Profil pro
    Développeur de jeux vidéo
    Inscrit en
    août 2004
    Messages
    1 717
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur de jeux vidéo
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2004
    Messages : 1 717
    Points : 3 285
    Points
    3 285
    Par défaut
    Je ne comprends pas pourquoi PPL et ITBB ne sont pas dans la liste, ils sont autant orienté parallélisme que concurrence (et même que c'est leur principal interet je trouve, avec tous les outils pour les Task...)

Discussions similaires

  1. Quelle API pour traiter des paramètres d'un programme en ligne de commande ?
    Par Pierre8r dans le forum API standards et tierces
    Réponses: 2
    Dernier message: 19/12/2008, 11h36
  2. [Runtime]Quelle API pour ne pas impacter le client?
    Par Jean_Benoit dans le forum C++Builder
    Réponses: 1
    Dernier message: 28/11/2006, 10h38
  3. Quelle API pour la 3D?
    Par babarpapa dans le forum 3D
    Réponses: 3
    Dernier message: 05/10/2006, 09h33
  4. Quelle API pour detecter un Exe qui s'execute.
    Par caviar dans le forum MFC
    Réponses: 3
    Dernier message: 20/04/2006, 13h26
  5. [J2EE] quelle API pour Excel choisir ?
    Par vallica dans le forum Documents
    Réponses: 4
    Dernier message: 19/04/2006, 14h24

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo