Bonjour à tous et bienvenue à tous ceux qui participent au cours Java et le multithreading !

Ce cours sera ouvert avec des exercices certifiants à partir du 30 juin, et vous y découvrirez le monde de la programmation parallèle. Cet aspect de la programmation est sans doute l'un des plus difficiles car il nécessite de bien comprendre le comportement de vos machines face à des programmes multithread, sans quoi vous vous exposerez au risque de planter la machine de l'utilisateur.

Je vous invite à poster vos questions ici, j'essaierai de répondre régulièrement, mais n'hésitez pas à discuter ensemble et vous entraider. 

À bientôt et bon cours !

-
Edité par Anonyme 9 juin 2015 à 10:06:56

Lu'!

cysboy a écrit:

Cet aspect de la programmation est sans doute l'un des plus difficiles car il nécessite de bien comprendre le comportement de vos machines face à des programmes multithread, sans quoi vous vous exposerez au risque de planter la machine de l'utilisateur.

Cette phrase est bizarrement tournée. A moins que l'OS soit à l'ouest, il n'y a pas vraiment de raison qu'un programme plante la machine, même en multi-thread. Ou alors éventuellement par un déni de service mais on peut aussi le faire avec un programme séquentiel. Si on parle simplement de faire un programme qui crash, qui deadlock, qui livelock, ben, on peut aussi écrire des conneries en séquentiel, il y a pas de raison.

Concernant le cours, je n'aime pas la notion de "protéger les variables". En fait ce qu'on veut protéger dans l'exécution du programme parallèle c'est ses propriétés de cohérence, ses invariants, et c'est dans le but de préserver cette cohérence qu'on verrouille des éléments. Nos classes maintiennent des invariants à propos de leur données, ce qu'on verrouille c'est le droit de briser cet invariant pendant quelques instructions pour ensuite le restituer, mais typiquement, si on est capable de préserver cet invariant sans verrouillage, on aurait tord de s'en priver.

Surtout que le locking est une des manières de créer la séparation des accès dont on a besoin pour faire des programmes multi-threadés robustes mais ce n'est pas la seule.

Les explications du cours présentent bien l'idée de préserver les propriétés mais le titre est à mon sens très mal choisi.

Concernant l'approche globale du cours, je lui ferai le même reproche qu'à beaucoup d'autres cours dans beaucoup d'autres domaines. On commence par montrer les techniques compliquées qu'il ne faut pas utiliser à moins d'avoir de très bonnes raisons de le faire pour ensuite voir celles qui sont simples et efficaces (conteneurs concurrents, modèles BSP, etc).

La meilleure manière de faire de bons programmes concurrents c'est d'avoir un minimum de points de concurrence, et d'utiliser pour ces points de concurrence des éléments qui ont déjà été développés et éprouvés par d'autres parce qu'on a 90% de chance d'écrire une connerie en les implémentant nous mêmes. Typiquement en s'arrangeant pour ne jamais avoir à bosser sur des données communes et donc en ayant une architecture où les données sont organisées en arbre et surtout pas en DAG. Et en transmettant aux threads, par l'intermédiaire de nos SDD concurrentes toutes belles et déjà faites, des objets dont on a la certitude qu'ils sont spatialement inaccessibles par d'autres.

cysboy a écrit:

Voilà, vous avez appris à protéger vos données des accès concurrents. C'est l'aspect primordial de la programmation concurrente !

Et c'est là que je ne suis pas vraiment d'accord. Ce qui est primordial à mon sens en concurrence c'est d'avoir un maximum de parallélisme, pour un minimum de points concurrents, et d'utiliser pour ces points concurrents des structures de données qui nous permettent de ne pas avoir à écrire nous-mêmes les synchronisations et donc de ne pas avoir à écrire ces protections. On n'a pas envie de poser manuellement les verrous, sémaphores, attentes, signaux et compagnie, parce que les chances de faire une connerie en le faisant sont très élevées.

HS : Il est amusant de voir à quel point gérer le locking (au sens mutex) en Java est aussi tordu que le faire en C. Pendant un très long moment, l'argument de Java par rapport à C++ (hors éco-système) était la présence du GC. C++ a trouvé sa solution à travers le RAII et le résultat est que cette technique fonctionne (contrairement au GC) sur toute ressource, rendant la gestion du cas tordu : exception dans une section à verrou, beaucoup plus simple en C++ qu'en Java.

-
Edité par Ksass`Peuk 5 juillet 2015 à 20:38:32

Bonjour,

Nous réalisons un POC sur un objet connecté pour remonter des données environnementales et à chaque capteur correspond une "task", du coup, je me suis dit pour faire les choses correctement il faut que je suivie ce cours. j'ai toutefois une difficulté pour l'exo de simulation de conversation qui sous Eclipse ou rien ne s'affiche dans la console.

allez, je poursuit tout de même et reviendrais plus tard sur cet exercice

En tout cas un grand merci pour vos cours.

Jérôme.

J ai eu plus ou moins le meme problème que JEROME : sous  eclipse, Journaliste et Personne interviennent une seule fois et le programme ne progresse plus: PPDA, posez votre question : 

Bonsoir,

Idem, même problème pour moi...

Chez moi, la classe Journaliste soulève une IllegalMonitorStateException quand elle libère le thread associé aux questions du journaliste.

Cysboy, votre réponse ?

Thanks !

Joe

PS : ci-dessous, le code de ma classe Journaliste

package actif;

import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
import java.util.concurrent.locks.Condition;
import java.lang.Runnable;
import java.util.Set;
import java.util.HashSet;
import java.util.Iterator;

public class Journalist implements Runnable{
    
    Interview interview;
    protected Set<String> questions = new HashSet<String>();
    Lock lockJournalist;
    Condition conditionLockJournalist;
    Condition conditionLockInterviewee;
    
        public void run(){
            
            Iterator it = questions.iterator();
            this.lockJournalist.lock();
            try{
                while(it.hasNext()){
                    System.out.println(it.next());
                    this.conditionLockInterviewee.signalAll();
                    this.conditionLockJournalist.await();
                }
             }
             catch(InterruptedException e){
                        e.getMessage();
             } 
                this.lockJournalist.unlock();     
        }
    
    Journalist(Interview interview, Lock lockJournalist, Condition conditionLockJournalist, Condition conditionLockInterviewee){
        
      this.interview = interview;
      this.lockJournalist = lockJournalist;
      this.conditionLockJournalist = conditionLockJournalist;
      this.conditionLockInterviewee = conditionLockInterviewee;
      
      for (int i = 1; i <= 10; i++){
          String question = "Alors, la question "+i+" est "+ "Q "+i;
          this.questions.add(question);
      }
      
    }
}

Bonjour,

Je tiens d'abord à remercier cysboy pour ses cours sur Java.

L'objet de ce message concerne l'unique moyen de notation de ce cours et donc l'unique moyen d'obtention du certificat : le quiz !

Le problème se situe au niveau de la question N°2 (qu'est-ce qu'une opération atomique) : la réponse donnée par le système est erronée et contredit l'explication fournie avec, qui elle, est juste (ainsi que le passage qui en parle dans le cours) ...

Par précaution, j'ai vérifié sur une source extérieure : https://fr.wikipedia.org/wiki/Atomicit%C3%A9_%28informatique%29

Étant donné qu'il n'y a que 10 questions, cette réponse erronée pénalise les élèves de 10 % sur la note de ce cours certifiant !

-
Edité par philippebeck 3 novembre 2015 à 18:21:40

@Abramech : il faut avertir le staff d'openclassroom pour qu'il vérifie.

Je n'ai malheureusement plus le détail de toutes les questions des quizz en tête...

Bonjour, 

Merci pour ce MOOC, tres interessant

Une rapide question : ne peut-on pas se contenter d'une seule condition (question dans ce cas précis) en l'implémentant de la facon suivante:

try{

...

question.signalAll();

question.await();

Merci,