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 God . É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/
[^] # Re: Ou pas ?
Posté par BFG . Évalué à 2.
Voir également ce qu'en dit Mailinator.
[^] # Re: Ou pas ?
Posté par Krunch (site web personnel) . Évalué à 1.
Ou C10K (cité dans la présentation de mailinator) : http://www.kegel.com/c10k.html
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Ou pas ?
Posté par MrLapinot (site web personnel) . Évalué à 3.
C10K est pas mal pour comprendre l’historique du problème mais franchement daté.
# Un reddit francais
Posté par Judas Iscariote . Évalué à 1. Dernière modification le 20 janvier 2012 à 20:59.
Ahhh, ce serait bien un reddit francais, on pourrait avoir un /r/troll
[^] # Re: Un reddit francais
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
Reddit? Cette pale copie des journaux bookmarks?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Un reddit francais
Posté par Judas Iscariote . Évalué à 2.
Et des pertinentages/moinssages en plus!
# Obsolete
Posté par reno . É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 Guillaume Knispel . Évalué à -2.
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 MrLapinot (site web personnel) . É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 Guillaume Knispel . É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 c^3 . É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 Ontologia (site web personnel) . É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 MrLapinot (site web personnel) . É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 Ontologia (site web personnel) . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.