Betriebssystem



  • Hallo,

    stimmt es dass ein Betriebssystem nur Prozesse kennt , aber keine Threads ?
    Threads sind nur Programm intern .


  • Mod

    Nein. Die Aussage ist total falsch, ich weiß nicht einmal wie du da drauf kommst. Ich empfehle etwas Lesestoff:
    http://en.wikipedia.org/wiki/Thread_(computer_science)
    http://en.wikipedia.org/wiki/Operating_system



  • In dieser allgemeinen Formulierung ist die Aussage natuerlich falsch. Aber es wird mit Sicherheit auch Betriebssysteme geben, die nativ keine Threads unterstuetzen und man sich darum selber kuemmern muesste.



  • hmm

    wie ist das denn wenn ich z.B. in meinem CSharp Programm einen thread erzeuge.
    Und dann z.B. thread.Sleep(100) mache .

    Jetzt ist es aber Programm intern



  • Nein, du setzt nur einen Befehl an Windows ab, dass es deinen Thread ca. 100ms schlafen legen soll. Sprich Windows teilt dem Thread einfach 100ms lang keine CPU-Ressourcen zu.


  • Mod

    Um mal konkret zu werden: Alles was du Betriebssystem nennst (weil du meinen Link nicht gelesen hast und daher komische Vorstellungen über die Bedeutung des Wortes hast) kennt Threads als kleine aber wichtige Einheit zur Verwaltung von Systemressourcen (wie dir in meinem anderen Link erklärt worden wäre, den du auch nicht gelesen hast).



  • mich würde trotzdem mal intressieren wie ein Betriebssystem einen Prozess in Threads zerlegt. Programm = Prozess; Aufgerufene Methoden = Threads.
    Ungefähr so ?



  • Lesen bildet! Hier hat schon jemand Links eingestellt!



  • Also erstmal, ich glaube schon dass es Betriebssysteme zumindest gegeben hat, die nur Prozesse kennen. Zumindest wenn man nur den Kernel betrachtet. Irgendwo im *NIX Bereich gab's das mal. Da gab's dann Usermode Libraries die sich um Threads gekümmert haben.

    mich würde trotzdem mal intressieren wie ein Betriebssystem einen Prozess in Threads zerlegt.

    Das OS zerlegt gar nix in Threads. Das OS erstellt dir beim Starten eines Programms einen Prozess mit genau einem Thread drinnen, der die "main" Funktion ausführt (Einsprungspunkt des Programms halt, muss nicht unbedingt "main" heissen).
    Und wenn diese "main" Funktion dann irgendwo CreateThread (oder wie auch immer die Funktion heisst) aufruft, dann wird ein zusätzilcher Thread erstellt. Bzw. so viele wie das Programm eben erstellt.

    Natürlich können auch OS-Interne Teile selbst Threads erstellen wenn man bestimmte Funktionen aufruft. Oder thirdparty Libraries die man verwendet. U.u. auch ganz ohne dass man davon was mitbekommt, wenn diese "library-internen" Threads nur ein Implementierungs-Detail sind.
    Beispielsweise verwenden DirectShow und ADO intern eigene Threads um nur mal zwei zu nennen die mir auf die Schnelle einfallen.



  • Es gibt übrigens noch eine Unterscheidung zwischen Kernel-Level-Threads und User-Level-Threads. Zweitere kennt das Betriebssystem in vielen Fällen tatsächlich nicht. Sobald der OS-Scheduler dem Prozess Rechenzeit zuweist teilt ein interner Scheduler diese auf seine (User-Level-)Threads auf. Dies verursacht weniger Overhead bringt aber einige Nachteile mit sich...naja wie gesagt, lies einfach die Wikipedia-Artikel oder ein Buch über Betriebssysteme.

    MfG SideWinder



  • UNter Linux haben Threads Ähnlichkeiten mit Prozessen.
    Zumindestens wenn man ins /proc schaut.



  • Ethon_ schrieb:

    UNter Linux haben Threads Ähnlichkeiten mit Prozessen.
    Zumindestens wenn man ins /proc schaut.

    ... und was schaut man sich da genau an?



  • Ist ja echt krass, was hier an Halbwissen herumgeistert 😮

    Ich bin zutiefst schockiert, dass über so einen zentralen und für Entwickler direkt sichtbaren Designaspekt eines jeden Betriebssystems so viel Unwissen herumgeistert.

    Wie SideWinder, zum Glück, sagt lest (alle) mal besser ein Buch über Betriebssysteme. Man kann nicht parallele Programme schreiben, wenn man darüber nicht sehr gut bescheid weiß (exotische Sprachen ausgenommen).



  • Ethon_ schrieb:

    UNter Linux haben Threads Ähnlichkeiten mit Prozessen.
    Zumindestens wenn man ins /proc schaut.

    Linux kennt im ganz strengen Sinne weder das eine noch das andere, sondern Tasks, auf welchen dann Prozesse und Threads modelliert werden.



  • OSler schrieb:

    Ethon_ schrieb:

    UNter Linux haben Threads Ähnlichkeiten mit Prozessen.
    Zumindestens wenn man ins /proc schaut.

    Linux kennt im ganz strengen Sinne weder das eine noch das andere, sondern Tasks, auf welchen dann Prozesse und Threads modelliert werden.

    Magst du ausführen, wie du das meinst?



  • OSler schrieb:

    Ist ja echt krass, was hier an Halbwissen herumgeistert 😮 ...

    .. und wo geistert denn das Vollwissen herum 😕



  • abc.w schrieb:

    OSler schrieb:

    Ist ja echt krass, was hier an Halbwissen herumgeistert 😮 ...

    .. und wo geistert denn das Vollwissen herum 😕

    Hier geistert das Vollwissen herum:
    http://msdn.microsoft.com/en-us/library/ms681917(v=VS.85).aspx



  • Naja, Threads laufen unter Linux doch als Child"prozesse" ?
    Man kann einen Thread doch ganz normal über seine Prozess-ID ansprechen, wie einen "echten" Prozess.



  • fdfdg schrieb:

    OSler schrieb:

    Ethon_ schrieb:

    UNter Linux haben Threads Ähnlichkeiten mit Prozessen.
    Zumindestens wenn man ins /proc schaut.

    Linux kennt im ganz strengen Sinne weder das eine noch das andere, sondern Tasks, auf welchen dann Prozesse und Threads modelliert werden.

    Magst du ausführen, wie du das meinst?

    Ich weiß nicht was ich da ausführen soll. Linux bietet als Abstraktion der Hardware etwas an, dass sie Tasks nennen. Und die POSIX Schnittstelle modelliert auf diesen dann die klassischen Prozesse und die POSIX Threads.

    In Linux erstellst du einen neuen Thread mit dem clone system call und einen neuen Prozess ebenso mit dem clone system call. Es hängt nur davon ab was führ Flags du angibst, die kontrollieren wie viel Zustand die Elter- und Kind-Task teilen.



  • Interessant, danke!


Anmelden zum Antworten