[Livre] Programmation concurrente en Java

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 ?

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.

Citation:

---

Envoyé par benwit

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 :aie:

Citation:

---

Envoyé par benwit

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...

Citation:

---

Envoyé par divxdede

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.

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.

Citation:

---

Envoyé par hugo123

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é.

@Eric

Les exemples de code peuvent être téléchargés ici :
http://www.pearson.fr/info/?fa=text109

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"

Code:

---

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:

---

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 ?

Citation:

---

Envoyé par camus3

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

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

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.

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.