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

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 !

Programmation concurrente en Java
De Brian Goetz, critique par Eric Reboisson

Le , par benwit
10 commentaires

7PARTAGES

0  0 
Je viens de lire "Programmation concurrente en Java" et je vous le recommande vivement.

Une chose m'a particulièrement marqué :
Trop peu de développeurs se soucient de la justesse de leur programme. Un peu comme pour la propreté du code (cf Clean Code), ils sont nombreux à s'arrêter dès que ça fonctionne ! Or en ce qui concerne la concurrence, les conditions limites vont s'exprimer le plus souvent en production et non en développement.

Je ne dis pas qu'il faut faire systématiquement du code multithread (cela à un coût certain) mais au minimum de l'indiquer pour ceux qui viennent après. L'auteur fait d'ailleurs remarqué que même de nombreux frameworks connus ne l'indiquent pas et on est alors obligé de le deviner en se mettant à leur place !!! C'est pourquoi il propose à la fin de son ouvrage des annotations pour l'indiquer explicitement.

Quelle est votre opinion sur le sujet ?
Est-ce que vous y penser en développant ? Est-ce que vous y penser parce que vous avez des comportements étranges en production ?
Etes vous sensibiliser sur le sujet ? Allez vous faire gaffe à l'avenir ?
Que pensez vous de sa proposition des annotations ?

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

10 commentaires
Commenter Signaler un problème
divxdede
Avatar de divxdede
Membre éclairé https://www.developpez.com
Le 06/08/2010 à 11:16
Bonjour,
La javadoc de l'api standard est bien fichue de ce coté là est indique le plus souvent si une classe est 'thread-safe' ou non.
A mon sens, il s'agit avant tout d'un problème de documentation et l'annotation n'y changera pas grand chose. A savoir lorsqu'elle sera absente, on ne saura pas ce qu'il faut en conclure.
0  0 
Deaf
Avatar de Deaf
Membre éprouvé https://www.developpez.com
Le 06/08/2010 à 11:34
Citation Envoyé par benwit Voir le message
Trop peu de développeurs se soucient de la justesse de leur programme.
Je pense que cela vient du fait que nombre de développeurs ne sont pas à l'aise avec la concurrence. Beaucoup pensent résoudre les problème en métant un 'synchronized' devant LA méthode qui pose problème

Citation Envoyé par benwit Voir le message
ils sont nombreux à s'arrêter dès que ça fonctionne
Je confirme, la pratique trop souvent répandue est de se poser les questions de concurrence que lorsque des erreurs se produisent. Dès que ça semble rouler, on oublie cette vilaine bête noire...
0  0 
benwit
Avatar de benwit
Rédacteur https://www.developpez.com
Le 06/08/2010 à 11:45
Citation Envoyé par divxdede Voir le message
A mon sens, il s'agit avant tout d'un problème de documentation et l'annotation n'y changera pas grand chose. A savoir lorsqu'elle sera absente, on ne saura pas ce qu'il faut en conclure.
C'est juste.
Cependant, elle a l'avantage de normaliser et c'est sémantiquement plus robuste que dans un commentaire.
0  0 
hugo123
Avatar de hugo123
Rédacteur https://www.developpez.com
Le 11/08/2010 à 15:28
Je viens de finir le bouquin aussi.
Le sujet est intéressant, mais j'avoue avoir trouvé le livre indigeste par moment. Déjà je suis moins enthousiasmé que toi sur la traduction que je trouve désagréable. Beaucoup de mots sont traduits alors que j'ai l'habitude de les voir en anglais, du coup c'est perturbant.
Quand au dernier chapitre, j'ai pas pu aller au bout (le modèle mémoire de Java) ^^

Bon mais sinon il m'a vraiment servi. J'ai découvert des éléments du langage que je ne connaissais pas et j'ai vu des concepts que je ne connaissais pas bien.
J'en ai justement eu l'utilité le mois dernier et je pense que la lecture du livre m'a permis de remarquer des petits trucs que je n'aurais pas vu sinon.
0  0 
benwit
Avatar de benwit
Rédacteur https://www.developpez.com
Le 11/08/2010 à 16:58
Citation Envoyé par hugo123 Voir le message
Beaucoup de mots sont traduits alors que j'ai l'habitude de les voir en anglais, du coup c'est perturbant.
Tu as des exemples car je n'ai pas souvenir d'avoir été choqué.

Moi, dans les traductions, si l'auteur utilise un mot français qui s'utilise chez les développeurs francophones, cela ne me dérange pas.
En revanche, ce qui me gène, c'est quand par excès de zèle, un auteur invente une traduction ou pire mélange les deux (un coup je traduit, un coup je traduit pas).
Dans Coder Proprement, la traduction de Clean Code, "Map" est traduit par endroit par "carte" mais puisqu'il s'agit de l'objet Java, c'était inutile !

C'est parce que cette version française de "Prog. conc. en Java" ne m'a pas perturbé que j'ai trouvé la traduction correcte.
Maintenant, je comprends ton point de vue si des choses t'ont troublé.
0  0 
benwit
Avatar de benwit
Rédacteur https://www.developpez.com
Le 31/12/2010 à 11:02
@Eric

Les exemples de code peuvent être téléchargés ici :
http://www.pearson.fr/info/?fa=text109
0  0 
hugo123
Avatar de hugo123
Rédacteur https://www.developpez.com
Le 31/12/2010 à 11:25
amusant, ils ont aussi mis en téléchargement les exemples de code à ne pas faire. A tout les coups il y a des gens qui ne vont pas lire la mention "ne le faites pas"
0  0 
camus3
Avatar de camus3
Membre éprouvé https://www.developpez.com
Le 01/01/2011 à 17:33
Code : Sélectionner tout 
Trop peu de développeurs se soucient de la justesse de leur programme. Un peu comme pour la propreté du code (cf Clean Code), ils sont nombreux à s'arrêter dès que ça fonctionne ! Or en ce qui concerne la concurrence, les conditions limites vont s'exprimer le plus souvent en production et non en développement.
Les développeurs font avec les ressources et le budget qu'on leur alloue. Et le client veux une seule chose , que le produit fonctionne.
Si la performance est un point critique alors le budget prend en compte la perf.
Vous trouvez toujours un dev plus futé que vous qui aura quelque chose à redire sur votre code , à développeur , développeur plus compétant.
Code : Sélectionner tout 
pourquoi tant qu'on a pas compris ce qu'est la thread-safety, on ne sait pas programmer !
Donc tout les codeurs qui codaient avant la popularisation du multi threading dans les langages ne savaient pas coder ?
0  0 
benwit
Avatar de benwit
Rédacteur https://www.developpez.com
Le 01/01/2011 à 22:12
Citation Envoyé par camus3 Voir le message
Et le client veux une seule chose , que le produit fonctionne.
Si la performance est un point critique alors le budget prend en compte la perf....
Certes, mais dans le point que je soulevai, il ne s'agit pas de performance mais de justesse du programme.
Que dira le client si vous lui vendez un programme en lui affirmant qu'il fonctionne alors qu'une fois en production, il se met à bugger (tourne en boucle, données corrompues, ...) vous irez toujours lui affirmer qu'avec un seul utilisateur, ça fonctionne ?!

Citation Envoyé par camus3 Voir le message

Vous trouvez toujours un dev plus futé que vous qui aura quelque chose à redire sur votre code , à développeur , développeur plus compétant.
Je ne dis pas le contraire et en restant sur mon analogie avec Clean Code, je comprend votre point de vue. En effet, pour ce qui est de la "propreté" du code ou encore de performance, il est probablement possible de faire mieux (ou différent).

En revanche, et je le réaffirme, un programme multithread qui marche sur la machine du développeur lorsqu'il est tout seul et échoue en production est tout simplement faux. Il ne répond pas au besoin exprimé. Il n'y a pas à tourner autour du pot, ce n'est pas du même ordre que la propreté.
Je pense qu'il y aura déjà suffisamment de risque de bugs pour un développeur expérimenté alors je n'ose imaginé pour un développeur qui n'a même pas conscience des problèmes de concurrence.

Citation Envoyé par camus3 Voir le message

Donc tout les codeurs qui codaient avant la popularisation du multi threading dans les langages ne savaient pas coder ?
Bien sûr que non s'ils ne faisaient pas des programmes multi-threading !
Et je pense même que ceux qui en faisaient avant la popularisation du multi threading en était conscient.
Ne me faites pas dire ce que je n'ai pas dit.
La programmation aujourd'hui est probablement plus accessible de même que les environnements multithreading et c'est pourquoi il faut être vigilant.
0  0 
sunzoo
Avatar de sunzoo
Membre du Club https://www.developpez.com
Le 23/01/2011 à 12:19
Bonjour,
je ne sais pas si c'est de l'humour mais à la page 9 l'auteur nous parle de "dreadlocks" pour les interblocages. ensuite c'est bien de deadlocks.
0  0 
Commenter Signaler un problème