Journal Sus aux threads

Posté par .
Tags : aucun
7
20
jan.
2012

Nal ;

Si comme moi vous avez le cerveau retourné par l'ACPI et que vous voulez à la fois faire une pause et apprendre des trucs et/ou diffuser la connaissance, je ne peux que vous enjoindre, sur un tout autre sujet, d'aller lire et propager Why Threads Are A Bad Idea (for most purposes) [pdf] qui déjà à l'époque avait tout compris. D'autant que comme le montre l'architecture délétère de certaines bibliothèques et logiciels de télécommunication libres connus, le schéma "Callbacks don't work with locks", B.A. BA qui devrait être enseigné à tout informaticien et que tout informaticien doté d'au moins 3 neurones devrait retenir à vie après ledit enseignement, semble méconnu de personnes pourtant très compétentes par ailleurs (et aussi de personnes très incompétentes par ailleurs, mais dans ce cas c'est plus normal). Je tiens à rétablir la balance du côté où les choses ne se vautrent pas lamentablement un soir de pleine lune à cause de la loi de Murphy et d'une méconnaissance crasse si facile à corriger.

Je suis un peu réservé sur la dichotomie thread vs. event qui semble transpirer du papier (mais sa conclusion est saine).

Enfin il faut se rappeler que c'est un document d'il y a 16 ans. D'ailleurs certains inconvénients des deux côtés ont partiellement disparus depuis, selon les langages et les systèmes (ex : côté événements les langages modernes fournissent des closures et fonctions anonymes ou autres mécanismes proches qui peuvent faciliter la vie, sur les threads tournant sur du mono CPU l'overhead du locking est devenu négligeable).

Le fil de discussion associé sur reddit : http://www.reddit.com/r/programming/comments/ooqic/ahead_of_his_time_why_threads_are_evil_and_events/

Blah, plop !

  • # Ou pas ?

    Posté par . Évalué à 3.

    Le fil de discussion contient aussi ça :

    Why Events Are A Bad Idea (for high-concurrency servers) => http://www.usenix.org/events/hotos03/tech/full_papers/vonbehren/vonbehren_html/

  • # Un reddit francais

    Posté par . Évalué à 1. Dernière modification le 20/01/12 à 20:59.

    Ahhh, ce serait bien un reddit francais, on pourrait avoir un /r/troll

  • # Obsolete

    Posté par . Évalué à 7.

    Il y a 16 ans on pouvait se permettre d'utiliser un seul CPU, maintenant ce n'est pas une bonne idée et par défaut les evenements c'est mono-CPU.

    Ceci dit, il y a thread et thread par exemple en D les variables globales sont thread local par défaut et il faut les marquer "shared" pour qu'elles soient partagées par plusieurs thread, ce qui est déjà un progrès.

    Enfin par rapport au C++ pas par rapport à Ada.

    • [^] # Re: Obsolete

      Posté par . Évalué à -2.

      Il y a 16 ans on pouvait se permettre d'utiliser un seul CPU, maintenant ce n'est pas une bonne idée et par défaut les evenements c'est mono-CPU.

      Merci, ô grand sage, de nous résumer en une phrase la règle universelle de la quintessence de l'informatique moderne.

  • # L'article qui a vraiment tout compris

    Posté par (page perso) . Évalué à 10.

    Les événements, c'est tellement bien que ça fait des noeuds dans le cerveau quand tu essayes d'écrire des programmes conséquents avec.

    Bon, c'est le sujet de ma thèse, alors je ne pouvais pas ne pas réagir. En même temps, j'ai un peu la flemme de te refaire toute la bibliographie sur le sujet, mais va au moins lire cet article :
    http://www.usenix.org/event/usenix02/adyahowell.html

    Eux, ils ont vraiment tout compris, à savoir que le débat "threads vs. événements" est un gros troll qui mélange deux problèmes orthogonaux : coopératif vs. préemptif et gestion de la pile automatique vs. manuelle.

    Après, on peut continuer avec la demi-douzaine de méthodes pour interfacer threads et événements, voire convertir les uns vers les autres automatiquement.

    • [^] # Re: L'article qui a vraiment tout compris

      Posté par . Évalué à 2.

      "Je suis un peu réservé sur la dichotomie thread vs. event qui semble transpirer du papier (mais sa conclusion est saine)."

      Merci.

    • [^] # Re: L'article qui a vraiment tout compris

      Posté par . Évalué à 2.

      +1, ce qui compte c'est les techniques de communication entre divers "processus concurrents" (au niveau conceptuel). Et pour ça il y a plusieurs techniques qui marchent même pour des threads préemptifs, que ce soit message passing, STM, les verrous/conditions/sémaphores de nos aïeux. Certains langages mélangent d'ailleurs threads et évènements (un pool de threads qui exécutent des callbacks, par exemple en Haskell) pour utiliser tous les coeurs mais avoir quand même des IO bloquants etc. etc.

      The cake is a lie.

    • [^] # Re: L'article qui a vraiment tout compris

      Posté par (page perso) . Évalué à 3.

      Ce serait intéressant que tu nous fasses une recension de ta thèse dans un journal. J'imagine que tu dois bien avoir quelques choses de pas trop gros qui résume un peu ?

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: L'article qui a vraiment tout compris

        Posté par (page perso) . Évalué à 2.

        Normalement, la partie « background » devrait être lisible par tous.

        Je fais un journal dès qu’elle est écrite :-) (C’est en cours…)

        • [^] # Re: L'article qui a vraiment tout compris

          Posté par (page perso) . Évalué à 2.

          Cool, merci :-)

          Si tu avais des pointeurs sur le même genre de problème appliqués aux langages fonctionnel, où la pile est un problème différent, ça m'intéresse..

          « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.