Dans la continuité de mes deux précédents articles, je voudrais aborder ici les bonnes approches de division en tâches dans le cadre du framework fork / join. Cela me permettra aussi de répondre ici à des questions envoyées par quelques précieux lecteurs (car oui, ce blog est lu par plusieurs personnes !). Le framework fork / join a pour objet de traiter de très grandes quantités de données, dans de très nombreuses tâches, tout en conservant le principe qu’une tâche doit effectuer un « petit » traitement. L’une des difficultés est de garantir que la quantité d’opérations réalisées par une tâche donnée reste limitée, et, surtout, n’augmente pas avec la taille globale du traitement.

Par exemple, dans un calcul matriciel, on ne veut pas que le temps de traitement d’une tâche dépende de la taille de la matrice à traiter.

Continuer la lecture de Java 7 : le fork / join divise pour mieux régner →

La présentation du framework fork / join, objet de notre épisode précédent ne comportait qu’un seul exemple. Cet exemple était simple, mais non trivial tout de même. J’y avais glissé une remarque, que, précieux et averti lecteur, tu n’auras pas manqué de relever en te disant : « encore une remarque en l’air, qui tombe à plat, ces blogs techniques, tous les mêmes ! ».

Cette remarque est la suivante :

Chaque calcul et chaîne de calcul doivent être exécutés dans la même réserve, pour des raisons que nous verrons plus loin.

Eh bien nous y sommes, au « plus loin ». Je te propose, précieux lecteur, d’explorer plus avant les choses, afin qu’aucune zone d’ombre ne subsiste dans ce merveilleux framework.

Continuer la lecture de Java 7 : plus loin dans le fork / join →

Un précédent article, Synchronisation et volatilité, traitait de programmation concurrente, et de la façon dont le JMM (Java Memory Model), avait été entièrement réécrit en Java 5 (JLS v3). Il laissait complètement de côté l’API java.util.concurrent, nouveauté de Java 5, écrite par Doug Lea, et conçue à partir de l’API edu.oswego, disponible en Java 4. Cette API a subi quelques évolutions entre Java 5 et Java 6 , et en subit encore en Java 7.

C’est à un petit bilan de l’existant, et un rapide tour de table des nouveautés que je te convie aujourd’hui, cher et précieux lecteur. Je parlerai surtout du framework fork / join, et de la façon dont on peut l’utiliser. Pour une fois, dans Java le Soir, on va parler de l’avenir. Note bien, que, plus le temps passe, et plus l’avenir a tendance à devenir le passé, ce qui finira aussi par arriver à ce qui est écrit ici !

Continuer la lecture de Java 7 : fork / join →

Les deux notions de synchronisation et de volatilité sont en train de prendre, depuis quelques années, une importance croissante. La généralisation des processeurs multicœurs, jusque dans les téléphones portables, fait surgir des bugs dans les applications Java, qui ne s’observaient pas auparavant.

Nous avons de la chance, nous autres développeurs Java, pour deux raisons. La première, c’est que nous avons une doc, la JLS (Java Language Specification, nous vivons sous le règne de la v3), qui spécifie tous les aspects du langage. La deuxième, c’est que cette doc comporte un chapitre 17, qui traite précisément des problématiques de la programmation concurrente.

Nous avons aussi deux malchances. La première, c’est que la JLS est vraiment un document pénible à lire. Et la deuxième, c’est que le chapitre 17 est totalement hermétique. Finalement, traiter des problèmes complexes dans des documents illisibles a au moins un mérite : ça peut justifier l’écriture d’articles dans des blogs techniques.

Donc, ne reculant devant rien pour te satisfaire, précieux et intrépide lecteur, je te propose une petite explication de texte sur la synchronisation en Java, qui, je l’espère éclairera ta lanterne sur une problématique majeure du développement, actuellement et pour les années qui viennent.

Continuer la lecture de Synchronisation et volatilité →