Der Martin: Mehr gleichzeitige Prozesse als CPUs?

Guten Abend in die Runde,

ich hab da mal eine Frage, die mich schon seit längerem beschäftigt.

Umgangssprachlich sagt man ja, ein Computer könne mehrere Programme gleichzeitig ausführen. Nimmt man es genau, ist diese Aussage aber falsch; ein Computer wechselt nur sehr schnell zwischen verschiedenen Programmen, so dass der Eindruck von Gleichzeitigkeit entsteht.

Allerdings kann eine Multicore-CPU natürlich tatsächlich mehrere Prozesse gleichzeitig bearbeiten - nämlich einen pro CPU-Core. Insofern wundere ich mich immer mal wieder, wieso das Linux-Tool top auf meinem PC mit Dualcore-CPU ab und zu mal drei, ganz selten sogar mal vier gleichzeitig laufende Prozesse angibt:

Screenshot von "top"

Wie kann das sein? Was verstehe ich hier falsch?

Live long and pros healthy,
 Martin

--
Für welches Tier mühen wir uns am meisten ab? - Für die Katz'.
  1. Hallo Der,

    ich kenne mich mit sowas kaum aus, aber vermute das hier dürfte in deine Richtung gehen.

    Gruss
    Henry

    --
    Meine Meinung zu DSGVO & Co:
    „Principiis obsta. Sero medicina parata, cum mala per longas convaluere moras.“
    1. Hallo Henry,

      entweder das, oder running/sleeping hat in dem Tool eine andere Bedeutung.

      In einem Multitasking-System hat ein Thread mehr Status als Run/Sleep.

      Sleep heißt: Der Thread kann nicht laufen, weil er auf ein externes Signal wartet (z.B. Festplatten-IO, oder eine Message von einem Socket, einer Named Pipe, oder ein irgendwie geartetes anderes Event).

      Running heißt: Er führt aktiv CPU-Instruktionen aus.

      Wenn TOP den Status der laufenden Threads bestimmt, dann ist er selbst im Status Running. Bei 4 Kernen können also nur 3 andere Threads auf "Running" stehen, bei 2 Kernen nur ein einziger anderer.

      Es gibt aber auch noch "Ready". Das sind die Threads, die gerne was tun würden, aber nicht können, weil der Scheduler meint, andere Threads wären gerade wichtiger. Und "Ready" können deutlich mehr Threads sein, als es Cores gibt. Das könnte man evaluieren, indem man ein Testprogram schreibt, das zehn Sekunden damit verbringt, vor sich hin zu loopen. Und das startet man vier oder acht mal.

      Rolf

      --
      sumpsi - posui - obstruxi
      1. Hallo Rolf,

        danke erstmal für deine Denkanstöße.

        In einem Multitasking-System hat ein Thread mehr Status als Run/Sleep.

        Ja, richtig. In top gibt es noch die Status D (das korreliert etwa mit der GUI-Meldung "<application> is not responding") und Z für Zombie. Außerdem noch zwei Status, die auftreten können, wenn ein Debugger im Spiel ist.

        Sleep heißt: Der Thread kann nicht laufen, weil er auf ein externes Signal wartet (z.B. Festplatten-IO, oder eine Message von einem Socket, einer Named Pipe, oder ein irgendwie geartetes anderes Event).

        Richtig.

        Running heißt: Er führt aktiv CPU-Instruktionen aus.

        Dachte ich bis gestern auch.

        Wenn TOP den Status der laufenden Threads bestimmt, dann ist er selbst im Status Running. Bei 4 Kernen können also nur 3 andere Threads auf "Running" stehen, bei 2 Kernen nur ein einziger anderer.

        Ja, und auch das ist eigenartig, weil top alle drei Sekunden (Default) eine Momentaufnahme macht und top selbst oft gar nicht unter den als "Running" markierten Prozessen ist.
        EDIT: Ich habe das jetzt mal ein paar Minuten beobachtet und komme zu der Erkenntnis, dass das ein Irrtum ist. Bei jeder Aktualisierung der Anzeige war top dabei.

        Es gibt aber auch noch "Ready". Das sind die Threads, die gerne was tun würden, aber nicht können, weil der Scheduler meint, andere Threads wären gerade wichtiger. Und "Ready" können deutlich mehr Threads sein, als es Cores gibt.

        Ja. In den man-Pages zu top habe ich mittlerweile einen unauffälligen, aber wichtigen Hinweis gefunden: Der Status R bedeutet in Wirklichkeit Ready. Dann wäre es aber wiederum erstaunlich, dass es immer nur so wenige sind ...

        Und die Bezeichnung "running" auch im Kopfbereich der Anzeige von top ist dann irreführend.

        Live long and pros healthy,
         Martin

        --
        Für welches Tier mühen wir uns am meisten ab? - Für die Katz'.
  2. Hi there,

    Wie kann das sein?

    Die Frage solltest Du nicht uns, sondern dem Kernel von Deinem Betriebssystem stellen. Der oder irgendein Scheduler darin teilt halt "einfach" die Prozesse zu. Irgendwas läuft ja immer, selbst wenn gerade kein Programm läuft;)

    Btw., warum verwendest Du nicht htop (s.shot von einem Raspi), das sieht man imho mehr als bei top und vor allem in Farbe...

    1. Hallo,

      Btw., warum verwendest Du nicht htop

      weil ich das nicht kenne. 😉

      das sieht man imho mehr als bei top und vor allem in Farbe...

      Naja, wenn ich mir deinen Screenshot anschaue und die Information, die htop anzeigt, sehe ich da keinen wirklichen Mehrwert für ein Tool, das ich mir erst zusätzlich installieren müsste.
      Ja, es ist bunt. Aber braucht man das?

      Live long and pros healthy,
       Martin

      --
      Für welches Tier mühen wir uns am meisten ab? - Für die Katz'.
      1. Ja, es ist bunt. Aber braucht man das?

        Es ist „nice2have“ und darüber hinaus auch die „Empfehlung der Woche“. Was Du im Bildschirmfoto nicht siehst ist die nette Belegung der Funktionstasten. Man kann sortieren, suchen, filtern und auf bequeme Weise Prozessen ein Signal senden oder deren Dringlichkeit verändern (als root: auch erhöhen).

        Was jetzt die „laufenden“ Prozesse betrifft, sind das schlicht und einfach jene, die dem Kernel mitgeteilt haben, dass diese gerne vom Sheduler etwas Rechenzeit mit dieser oder jener Dringlichkeit haben wollen (darunter natürlich jene bei denen der Sheduler so freundlich war, das zu gewähren).