Discussion :

[Yonito]

Bonjour tous le monde,

j'ai toujours entendu que le context switch s'effectue lors d'une operation I/O, ou un synchronised/lock ou chagement de priorite du thread etc.

Dans mon exemple ci dessous, n'ayant que 4 cores disponibles sur mon ordinateur je m'attends a ce que seulement 4 threads sur 5 soit en etat "running" et que le 5 eme ne soit jamais execute et pourtant tous les 5 ont ce meme etat.
J'en conclu donc qu'il y a bien des context switchs entre mes 5 threads.

Mes questions sont donc :

1. Pourquoi l'OS effectue tout de meme un context switch sachant que je n'ai ni I/O, ni synchronized etc ?

2. On a l'habitude dans certain cas bien precis d'utiliser un spin lock pour eviter les contexts switch mais j'en conclu que ce n'est donc pas fiable ?

3. J'ai lu quelque part que l'OS a partir d'un certain nombre de temps dans un spin lock effectue tous de meme un context switch ? qu'en pensez vous ?

4. Une de mes hypothese est que un core puisse en faite execute plus que un thread et que le context switch s’effectue entre les tasks d’un meme core? Cela ne m’explique toujours pas que est ce que le trigger de ce context switch?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public class Tester {
 
    public static final int NUMBER_OF_THREADS = 5;
    public static void main(String[] args) {
 
        Runnable r = () -> {
            int i = 0;
            while (true) {
                int i = 1 + 1;
            }
        };
 
        for (int i = 0; i < NUMBER_OF_THREADS; i++) {
            Thread t = new Thread(r, "Thread_" + i);
            t.start();
        }
    }
}

[Drowan]

4 : Le nombre de thread n'est pas liés aux nombre de coeurs, comme expliqué ici (c'est pour du C, mais le principe est le même).
Tu peux donc en théorie faire tourner 4000 thread sur 1 seul coeur.

De plus, si je me rappelle bien de mes cours d'OS, il n'y a pas de changement de context entre les threads. Les threads partagent tous le même context (celui à partir duquel ils ont été créés).
Le changement de context à lieu lors de changement entre process.

[thelvin]

Et pour information, l'OS va forcément interrompre les threads de temps en temps même s'ils ne le font pas eux-mêmes, puisqu'il lui incombe de simuler que tout ce qui peut être en train de tourner soit en train de tourner simultanément.

On parle de 4 cœurs avec les ordinateurs modernes, mais il n'y a pas si longtemps, on avait des ordinateurs avec un seul cœur et qui faisaient tourner Windows XP. Ça ne les empêchait pas d'avoir une trentaine de programmes qui faisaient leur travail en même temps, qu'ils fassent ou pas des I/O. L'OS se contente simplement de les interrompre régulièrement pour confier le processeur au prochain programme qui attend son tour. Cela étant dit, l'OS qui interrompt le processeur, c'est une I/O.

[Yonito]

On parle de 4 cœurs avec les ordinateurs modernes, mais il n'y a pas si longtemps, on avait des ordinateurs avec un seul cœur et qui faisaient tourner Windows XP. Ça ne les empêchait pas d'avoir une trentaine de programmes qui faisaient leur travail en même temps, qu'ils fassent ou pas des I/O. L'OS se contente simplement de les interrompre régulièrement pour confier le processeur au prochain programme qui attend son tour. Cela étant dit, l'OS qui interrompt le processeur, c'est une I/O.

Donc l'equation 1 core = 1 execution n'est pas exacte ? Si un core peux executer en parrallel reel plusieurs tasks, pourquoi insistons-nous sur le fait qu'il faut avoir dans l'ideal un thread par core si ce n'est pour eviter des context switches ?

[Drowan]

Ton coeur va simuler du parallèle :

• Il va exécuter la tache 1 pendant 10ms
• Puis interruption
• puis tâche 2 pendant 20ms
• Puis interruption
• tâche 3 pendant 11ms
• interruption
• re-tâche 2 pendant 15ms
• etc...

Ce qui fait qu'à échelle humaine, tu n'aperçois pas ces opérations et les tâches se déroulent en parallèle.

Mais effectivement si tu veux optimiser au maximum les capacités, en ne méttant qu'1 thread (tâche) par coeur, tu évite les instant d'interruption.

NB : Avec des fréquences supérieures au GHz de nos jours, les durées des tâches sont pas en ms mais plutôt en micro

[Yonito]

Ton coeur va simuler du parallèle :

• Il va exécuter la tache 1 pendant 10ms
• Puis interruption
• puis tâche 2 pendant 20ms
• Puis interruption
• tâche 3 pendant 11ms
• interruption
• re-tâche 2 pendant 15ms
• etc...

Ce qui fait qu'à échelle humaine, tu n'aperçois pas ces opérations et les tâches se déroulent en parallèle.

Mais effectivement si tu veux optimiser au maximum les capacités, en ne méttant qu'1 thread (tâche) par coeur, tu évite les instant d'interruption.

NB : Avec des fréquences supérieures au GHz de nos jours, les durées des tâches sont pas en ms mais plutôt en micro

On est donc d'accord il n'existe pas de reel parallelisme sur un seul core comme l'a ete di precedement. Un core ne peux execute qu'une et unique tache a un temps t
En revenant a mes questions d'origines, comment expliquer qu'il y est un context switch sur mon petit code sachant que je n'ai pas de I/O, synchrnoized etc ?

[Drowan]

cf : wikipedia (en)
Le context switch peut être déclencher par le séquenceur. Il peut alors avoir lieu ni sur une I/O ni un synchronized.
Ce qui permet d'éviter qu'un processus ne monopolise un coeur.

Ou alors je comprend pas ta question

[Yonito]

cf : wikipedia (en)
Le context switch peut être déclencher par le séquenceur. Il peut alors avoir lieu ni sur une I/O ni un synchronized.
Ce qui permet d'éviter qu'un processus ne monopolise un coeur.

Ou alors je comprend pas ta question

L'article de Wikipedia parle du context switch a l'echelle d'un processus. Est ce la meme logique a l'echelle d'un thread ?

Si oui, un spin lock ne peux que reduire le nombre de context switch mais ne pourra jamais les empecher totalement ?

[Drowan]

cf : https://fr.wikipedia.org/wiki/Commutation_de_contexte
C'est la même logique à l'echelle du thread (appelé processus léger dans l'article). Dans l'article anglais il ne détail pas la différence.
La seule différence et le temps/la complexité du context switch car un thread partage le même espace mémoire que son père.

[thelvin]

Si oui, un spin lock ne peux que reduire le nombre de context switch mais ne pourra jamais les empecher totalement ?

Ça a toujours été la seule idée.

Le spinlock évite un context switch qui aurait été certain avec d'autres formes de synchronisation si le verrou n'est pas libre.

Mais il ne change rien au fait qu'un thread se fait interrompre comme tout le monde pour laisser le microprocesseur aux autres programmes qui en ont besoin. C'est un état de fait qui n'a rien à voir avec la question d'accès aux ressources partagées.

Le spinlock lui, ne s'intéresse à rien d'autre que l'accès aux ressources partagées. Normal donc que la question du spinlock ne s'intéresse pas aux problématiques générales.

[Yonito]

OK, merci a tous je cloture cette discussion !