Cours particuliers en informatique Nice

Cours particuliers d'informatique à Nice – De la programmation concurrente au multithreading

Deux fonctions s’exécutent « en même temps » ? Ton cerveau crie bug… et c’est souvent ce qui arrive.
Tu incrémentes un compteur partagé ; parfois il affiche 10, parfois 9. Pas logique ? Bienvenue dans la condition de course.

(A) Les blocages classiques en informatique :

• Thread, processus, tâche : quelle différence ? On mélange tout et on ne sait plus qui partage quoi.
• Section critique : c’est le bout de code qui doit être exécuté seul ; sans verrou, c’est la pagaille.
• Ordonnanceur : il choisit quel thread s’exécute, mais personne ne te montre ses règles.
• Deadlock : deux verrous croisés, plus rien n’avance, tu redémarres la VM sans comprendre.

Résultat : tu compiles, ça marche presque… puis l’enseignant lance un test multi-thread et tout plante.

(B) Atelier solutions — on prend chaque bug par la main

1. Condition de course
   • On la provoque volontairement : un simple compteur partagé entre deux threads Python → résultat aléatoire.
   • On la repère : impression de la variable + time.sleep() pour créer le conflit visible.
   • On la corrige : mutex (threading.Lock), monitor Java (synchronized), ou objet std::mutex en C++.
2. Deadlock circulaire
   • Exemple concret : transfert bancaire : thread A verrouille compte 1 puis compte 2, thread B l’inverse → blocage.
   • Outil visuel : on dessine le graphe d’attente pour que tu voies le cercle.
   • Prévention : hiérarchie fixe des verrous ou acquisition try-lock avec timeout.
3. Thread famélique (starvation)
   • Diagnostic : profiler (htop, jvisualvm, perf) → un thread à 95 % CPU, les autres à 0.
   • Remède : thread pool (java.util.concurrent.Executor), file de tâches (queue.Queue Python), ou parallélisme moderne (std::async C++17).
4. Variables non synchronisées
   • Concept : mémoire cachée du CPU → tes threads ne voient pas tous la même valeur.
   • Solution : mot-clé volatile (Java), std::atomic (C++), ou verrou léger (AtomicInteger, multiprocessing.Value).

(C) Flexibilité UniProf – Nice : cours à la carte

• “Debug live” (30 min) : avant le TP, on reproduit ton bug sur écran partagé et on le corrige.
• Mini-série “Design Patterns concurrents” : 4 séances = producteur/consommateur, lecteurs-rédacteurs, futures/promesses, barrière cyclique.
• Visio si tu es à Valrose/Sophia et que tu veux éviter le bus, présentiel si tu préfères un tableau blanc.

(D) Des profs côté système, mais surtout pédagogues

• Ingénieurs ou docteurs spécialisés en systèmes concurrents (Linux embarqué, Java backend, etc.).
• Habitués aux vrais bugs de TP : ils savent qu’un étudiant découvre la concurrence en la cassant.
• Expliquent la théorie après la pratique : tu vois le problème, puis tu poses un nom dessus.

(E) Comment réserver ? Simple comme un pthread_create

1. Formulaire 60 s : ton langage (C/Java/Python), ton bug préféré, ton délai.
2. Proposition sous 48 h max d’un prof qui parle ton langage (et connaît ton IDE).
3. Choix de créneau : 30 min juste avant le contrôle ou bloc intensif de 2 h ? C’est toi qui décides.
4. Session : partage d’écran, correction, mini-fiches PDF + exos pour t’entraîner.

Résultat : tu lances tes tests multi-threads, rien ne plante. Et surtout, tu sais expliquer pourquoi.