Reprise du message précédent :

ton père t'as jamais dis que c'était pas nécessaire si l'opération était atomique ?  

à part TSL, je connais rien d'atomique  
plonk

Un tranfert d'une valeur de 32bits entre registre et mémoire n'est pas atomique ?? Pourquoi ??  
 
Edit: Ah ouais, d'accord, tu parlais de l'opération d'affection "a=b" en java, qui donnait un certain nombre d'instructions en assembleur ? Alors évidement c'est pas atomique.

Le problème, n'est pas trop ceux qui en ont peur, mais plutôt les gens qui n'en ont pas peur.
 
Qui se tappe une analyse formelle de sa concurence quand il développe en multithread ? Déjà que personne ne tente un tant soit peu de prouver que son programme en thread unique fonctionne alors dans le mutithread, c'est le festival du n'importe quoi ; à leur décharge, ils n'ont en général ni la formation ni les outils adaptés (java  par ex. est fait pour exprimer des changements d'états d'objets, pas des comportements de threads).
 
un lien que j'ai déjà passé, à titre d'illustration : http://ase.arc.nasa.gov/visser/jpf/jdc.html  
(ils ont oublié que la concurrence concerne aussi la partie statique)
 
Je pense qu'il vaut mieux en avoir peur que de se lancer inconsidérément dedans et planter un gros quake.

Taz, ton post n'est peut-être pas trolleux, mais de mon point de vue, il déborde pas mal sur la mauvaise foi.
 
Sun ne peut pas garantir que le portage de toutes les applications Java se fera sans recompilation, tout simplement parce que même en Java, il est assez facile décrire du code dépendant de la plate-forme. Certes c'est plus difficile qu'en C ou en C++ (où là, pour le coup, c'est difficile d'écrire du code non-dépendant de la plate-forme), mais c'est possible.
 
Un seul exemple, trivial : dans ton appli, il y a du code natif, écrit en C ou en C++ : à tous les coups, il faudra recompiler et faire des adaptations dans cette partie-là. Et ces adaptations peuvent impacter le code Java.
 
Pour avoir développé pendant plusieurs années sur du logiciel système portable multi-Unix/Windows NT, écrit en C, C++ et un peu en Java, je connais la difficulté d'obtenir du code parfaitement portable, réellement indépendant du boutisme et de la taille de l'int du processeur. Et je peux te dire que le travail de portage d'un soft de l'ordre du million de lignes de code, au lieu de durer des mois et des mois à plusieurs personnes s'il est écrit en C/C++ (même propre), dure à peine quelques jours à une seule personne s'il est écrit en Java.

C'est quoi le boutisme ?? ca veut dire big/little endian ?

Yep! Petit-boutiste et gros-boutiste sont les traductions françaises de "little-endian" et "big-endian". Et le boutisme tout court, les anglophones appellent ça "the endianness" (comme si ça avait une importance de différencier les petits indiens des gros indiens...     ).
 
edit> Je parle du boutisme, parce qu'en plus, le logiciel dont je parle était client/serveur, et le serveur et le client pouvaient être sur des machines complètement différentes, genre le serveur sur Sun/Solaris64 (gros-boutiste 64 bits) et le client sur Intel/Windows NT 4 (petit-boutiste 32 bits).

Juste pour rappeller que ce terme vient du monde de Gulliver où 2 clans s'affrontent : ceux qui mangent leur oeuf en començant par le gros bout et ceux qui commencent par le petit bout. Je pense qu'il est pas mal de garder ça à l'esprit lors de la traduction.
 
http://web.lycee-hainaut.org/pedag [...] lliver.htm

 
 
(sans ça, ça aurait pu tourner graveleux )

 
autant opté pour java, il a fait ses preuves