Java simultanéité cynisme est-il allé trop loin?

Question

Je me demandais si certains d'entre vous qui ont de l'expérience dans la simultanéité de la programmation pourrait m'aider à interpréter un texte/philosophie correctement.

J'ai une copie de Bruce Eckel grand tome Penser En Java (4e éd) qui a une assez bonne couverture d'un certain nombre de domaines de Java, qui sont un peu difficile pour les débutants. J'ai vraiment apprécié les chapitres sur les classes, les génériques, et les annotations -- ils ont dégagé un certain nombre de questions dans mon esprit.

Mais ensuite, j'ai obtenu la plupart de chemin à travers Eckel 193-chapitre sur la concurrence (après la lecture de l'excellent Java de la Simultanéité dans la Pratique) et a obtenu à ce bit: (p. 1278)

Avance rapide jusqu'à la sixième édition de le livre, et la plupart des nouvelles machines ont au moins deux cœurs sur eux, comme l'a fait la la machine que j'utilisais. Et j'ai été surpris quand il [l'un des programmes il a écrit pour le présent chapitre --J. S.] cassé, mais c'est un des problèmes. Ce n'est pas de Java faute; "écrire une fois, exécuter partout" ne peut pas s'étendre filetage sur simple contre multicœur machines. C'est un problème fondamental avec filetage. Vous pouvezeffectivement découvrez quelques problèmes de threading sur un machine mono-PROCESSEUR, mais il y a d'autres problèmes qui n'apparaissent pas jusqu'à ce que vous essayez sur un multi-PROCESSEUR machine, où votre fils sont effectivement en cours d'exécution en parallèle.

Et le plus important: vous ne pouvez jamais laisser - vous devenir trop confiant au sujet de vos connaissances en programmation quand il vient à la mémoire partagée de la simultanéité. J' ne serais pas surpris si, à un moment donné dans l'avenir, quelqu'un arrive avec un la preuve pour montrer que la mémoire partagée la simultanéité de la programmation n'est possible en théorie, mais pas dans de pratique. C'est la position que j'ai adopté.

WTF? Ai-je raté quelque chose? Java (+ autres langues/OS appels, d'ailleurs) de ne pas proposer des outils afin de fournir des garanties suffisantes de la simultanéité-correction pour exécuter des applications du monde réel? Ce n'est pas juste une question rhétorique, je me demande s'il y a une bonne documentation sur la façon de savoir si vous êtes la manipulation de quelque chose "correctement", ou s'il y a des "petits caractères" qui provoque une simultanéité de garantie pour être brisées.

par exemple: si vous utilisez un synchronized mot-clé sur la méthode d'une classe, est-ce vraiment garantir qu'un seul thread à la fois peut exécuter du code à l'intérieur de cette méthode sur un objet particulier? Ou est-il un piège si j'utilise un PROCESSEUR multicœur?

J'ai lu (mais pas entièrement comprise) un certain nombre de documents techniques sur les sémaphores, concurrente des listes liées, etc. et dans la plupart des cas, on dirait qu'ils ont pris grand soin de prouver rigoureusement l'exactitude de la simultanéité des primitives... mais maintenant, je ne suis pas sûr de la façon de traiter avec ce genre de choses. (Ma position de repli est d'ignorer ce chapitre de TIJ et relire Java de la Simultanéité dans la Pratique suffisamment de fois qu'il fait sens pour moi encore une fois.)

Answer 1

La synchronisation fonctionne très bien, c'est juste hellishly difficile à appliquer correctement partout où il est nécessaire - et si vous le faites mal ou oublier de faire quelque chose, votre code peut fonctionner correctement pendant des semaines, jusqu'à ce qu'il est déployé sur une machine de production avec plus de cœurs et le monde réel de la charge, rapidement provoquant une course à condition de manifester et de mutiler yor données avant de s'écraser de l'application.

Answer 2

Ne vous inquiétez pas, synchronized fonctionne OK. Je pense que Eckel est en train de dire que le thread basée sur la programmation simultanée est plein de gotcha attente autour de chaque coin. Faire simultanées trucs se sent toujours comme à la magie noire pour moi, bien que ma compréhension sûrement amélioré après la lecture de JCiP.

Answer 3

C'est la différence entre la théorie et la pratique. Théoriquement, il est possible d'écrire du code qui n'a pas de problèmes avec la concurrence. Cependant, la programmation simultanée peut devenir très complexe, très rapidement, de sorte que , pratiquement, il est très difficile de créer quelque chose de parfait.

Bien sûr, ce n'est pas nouveau. Théoriquement, il est possible d'écrire du code qui a zéro bugs. Mais, dans la pratique, il n'arrive jamais.

Answer 4

Je pense qu'il est trop pessimiste, et le problème est qu'il n'est pas en utilisant les outils appropriés.

Si vous utilisez principalement immuable structures de données et un design qui incarne utilise des primitives de synchronisation dans des petites parties du code et de plutôt utiliser les files d'attente, les travailleurs etc., il n'est pas si mal.

Answer 5

Souvent, les gens aimaient à se référer à elle comme "de leur donner assez de corde pour pendre eux-mêmes". Certains paradigmes de langage, tels que des fils ou des pointeurs de travail assez bien, sauf qu'ils sont extrêmement élevés sources de bugs.

Lâche pointeur erreurs en C et C++ sont endémiques, et sont donc la mise en cache/filetage bugs en Java. Vous pouvez mener un cheval à l'eau, mais vous ne pouvez pas convaincre de lire le manuel, et vous ne pouvez certainement pas la convaincre de code de ces types de choses avec soin et de manière cohérente. Le meilleur que vous pouvez faire est de trouver une abstraction (comme des références) qui couvre parfaitement et enlève le contrôle de la part des programmeurs. Si vous avez d'ajouter un "spécial" mot-clé comme la synchronisation, vous êtes déjà en difficulté avec les masses ....