Archiv verlassen und diese Seite im Standarddesign anzeigen : Multi-Core und die Dummheit der Giganten
Mistersecret
2005-05-17, 14:36:11
Zitat:
"Interessant war beispielsweise die Aussage, daß sowohl Microsoft- als auch Linux-Entwickler noch nicht wissen, wie sie für ein MultiCore-System ihr Betriebssystem vernünftig parallelisieren können. "
Haaaallooooo .... aufwachen .....
Sind die tatsächlich hirnamputiert oder was ? Wie einfach ist das denn bitte ? Man integriert einen "Core-Zuweisungs" Dienst, mit dem geregelt werden kann, wie das System die Prozesse verteilt. Standard: Das Basis-System läuft auf Core1, alle weiteren Anwendungen werden gleichmäßig auf die anderen Cores verteilt, der Reihe nach. Im Dienst-Menü können Sonderregeln für spezielle Anwendungen gesetzt werden, also zB werden immer drei Cores für TMpeg reserviert, sobald hier die Auslastung hochschnellt.
Irgendwie kommt es mir so vor, als würde die "da oben" den Bezug zur realen Anwendungs-Welt total verloren haben. Was meint ihr ?
Die Aussage ist quatsch. Sowohl Windows als auch Linux unterstützen schon seit Ewigkeiten Multithreading.
Was wohl gemeint ist, ist das der Kernel selber nicht auf mehreren Cores läuft, was aber auch nicht weiter schlimm ist.
Fatality
2005-05-17, 15:50:31
Woher stammt denn das Zitat?
Bokill
2005-05-17, 15:56:22
@Mistersecret
Interessant war beispielsweise die Aussage, daß sowohl Microsoft- als auch Linux-Entwickler noch nicht wissen, wie sie für ein MultiCore-System ihr Betriebssystem vernünftig parallelisieren können. Es ist zwar einfach, den Support für dieserart viele Cores einzubauen, jedoch auf Betriebssystem-Ebene davon in der Performance zu profitieren, soll wohl nicht so einfach zu realisieren sein ...
Zur Meldung von Golem.de Intel Inside: Strombedarf wird sinken (Teil 2) (http://www.golem.de/0505/38025.html)
Es geht um die effiziente Auslastung der vielen Kerne. Dass man irgendwie viele Kerne nutzen kann steht ausser Frage.
Wozu 8 Kerne bauen mit grottiger Auslastung, wenn bei 4 Kernen und geilem OS die 4 Kerne besser ausgelastet werden?
Auslastung! Das ist das Zauberwort für die Leistung von Vektorprozessoren, die reissen alles nieder, solange der Code linear, parallel vorliegt ... aber wehe es kommen Sprünge vor ... dann werden die Vektorprozessoren liebevoll geknüppelt von Skalarprozessoren. X86 ist ein Paradebeispiel für klassische Skalarprozessoren, aber auch die PowerPCs, MIPSs, ARMs dieser Welt sind klassische Skalarprozessoren ... die bekamen alle mehr oder weniger Intelligent dann CPU-Seitenwagen (SIMD Einheiten) mit Vektoreigenschaften (MMX, 3DNOW!, SSE, AltiVec, ARM SIMD ...).
Oder anders gesagt, die NEC SX-Reihe ist nur so gut wie die Software dazu. Ob nun SIMD, oder eben Multicore ... alles eine Frage der Auslastung ...
Wenn hirnlos nun Multicore propagiert wird, dann ist die nächste Leistungschallmauer in Sicht. Da verbrennen dann die Multicores sinnlos Strom für Nichts, Strom für Nichts wie bei dem alten Gigahurtz-Wahn.
Ein Vorteil hat aber Multicore, die Probleme sind altbekannt, und man hat in Clustern und Grids schon Spielmöglichkeiten, wie man viele Kerne ausnutzen kann. Und dort wird man ständig besser ... und ob man wirklich so viel Leistungskraft für den Standard-Desktop braucht, ist ja eine ganz andere Frage ...
Bo(2055)
drdope
2005-05-17, 15:58:15
Zitat:
Sind die tatsächlich hirnamputiert oder was ? Wie einfach ist das denn bitte ? Man integriert einen "Core-Zuweisungs" Dienst, mit dem geregelt werden kann, wie das System die Prozesse verteilt. Standard: Das Basis-System läuft auf Core1, alle weiteren Anwendungen werden gleichmäßig auf die anderen Cores verteilt, der Reihe nach. Im Dienst-Menü können Sonderregeln für spezielle Anwendungen gesetzt werden, also zB werden immer drei Cores für TMpeg reserviert, sobald hier die Auslastung hochschnellt.
Was meint ihr ?
Wenn so einfach ist wie du beschreibts --> programmier doch selbst und vertick es an MS.
Danach setzt du dich gemütlich in der Karibik zur Ruhe...
btw woher kommt diese Aussage? in welchen Kontext wurde sie getätigt?
Avalox
2005-05-17, 16:33:11
Homeanwendung trifft Informatik.
Mal sehen wer die Hausaufgaben besser gemacht hat. Wird eh Zeit für neue Gesichter bei den Helden der programmierenden Zunft.
(del676)
2005-05-17, 16:34:58
Homeanwendung trifft Informatik.
Mal sehen wer die Hausaufgaben besser gemacht hat. Wird eh Zeit für neue Gesichter bei den Helden der Programmierung.
is ne super aussage, was läuft auf den clustern mit >1000 cpus linux? (unix)?
:rolleyes:
Avalox
2005-05-17, 16:38:55
Grosse Datentechnik läuft nie auf Unix.
Deren King of the Hill halten übrigens von Unix das selbe, wie diese von Windows. Superdome verbreitet wohl einen Schrecken, wie Windows DB Server.
Grosse Datentechnik läuft nie auf Unix. :| :crazy2:
Avalox
2005-05-17, 16:44:42
Es gibt eine Welt jenseits derer. Sun aber auch HP probiert mit Superdome Fuss zu fassen. Vielleicht gelingt es ihnen ja auch. Ebenso wie es MS gelingt in der mittleren Datentechnik Fuss zu fassen.
Und HP und Sun verwenden kein Unix oder was?
Avalox
2005-05-17, 19:26:29
Natürlich verwenden sie Unix. Aber die Produkte sind ja auch die Neueinsteiger im Bereich, müssen erstmal Überzeugungsarbeit leisten.
Offene Systeme für Hobbyisten und Grossrechner ..das sind ja völlig verrückte Ideen. ;)
Ganon
2005-05-17, 19:42:20
Natürlich verwenden sie Unix. Aber die Produkte sind ja auch die Neueinsteiger im Bereich, müssen erstmal Überzeugungsarbeit leisten.
Falls du HP-UX und SunSolaris meinst, als System, dann sind das sogar zertifizierte Unix-Systeme.
Woher stammt denn das Zitat?
ich weiß es auch nimmer durch das ganze PS3 und Xbox gelatsche und gelese und was dagegen der PC schafft und bla bla bla...
aber irgendwo habsch diesen satz heute auch gelesen :rolleyes:
bin mir sehr sicher :)
mfg
St@N
Natürlich verwenden sie Unix. Aber die Produkte sind ja auch die Neueinsteiger im Bereich, müssen erstmal Überzeugungsarbeit leisten.
Offene Systeme für Hobbyisten und Grossrechner ..das sind ja völlig verrückte Ideen. ;)Du verwechselst gerade augenscheinlich Linux und Unix.
Es gibt in der Supercomputer Top100 eigentlich kein System das nicht auf einem Unix System läuft von den paar Windows Ausnahmen mal abgesehen.
Ach übrigens: Auf dem weltweit schnellsten System läuft Linux auf den I/O Nodes.
Avalox
2005-05-17, 20:14:14
Supercomputer sind ja auch keine Grossrechner.
Und Unix ist ein offenes System weil es nicht properitär ist, mit open source oder ähnliches hat es nichts zu tun.
Und was läuft auf Großrechnern deiner Meinung nach? Windows? Das ich nicht lache...
Die ganzen IBM Großrechner laufen z.B. entweder auf AIX, Linux oder anderen Unices.
Großrechner mit Intel Architektur gibt's ja eigentlich auch nicht, bis auf Itanium Maschinen. Und da lässt auch kein vernünftiger Mensch Windows drauf laufen.
Avalox
2005-05-17, 20:28:40
Nein keines von dehnen.
Ein wenig Unix, ganz vereinzelt.
Grossrechner Betriebssysteme sind z.B. z/os mit z/vm oder BS2000 oder UNIVAC 1100/2200.
Die Mainframe Neueinsteiger HP Superdome gelten nach wie vor, als die UNIX Systeme mit der besten SMP Unterstützung, wichtig für Grossrechner.
Ach z/OS usw. sind keine Unices? Da wäre ich jetzt davon ausgegangen.
Dann hast du wohl recht :)
Avalox
2005-05-17, 20:33:23
Mit z/vm kannst du dann lauter kleine virtuelle Unix Maschinen nachbilden.
Damit dann auch ein ungeübter Laie mit dem Grossrechner umgehen kann. ;)
Das z in z/os und z/vm steht für zero down time. Grossrechner werden ein- und nie wieder abgeschaltet. Wartungsarbeiten, Reparaturen, Um- und Aufrüstungen werden immer im vollen Betrieb durchgeführt.
Was ist eigentlich eine typische Anwendung für so ein Gerät?
Avalox
2005-05-17, 20:48:01
Na typischer Weise wurden/werden diese in Banken, grossen Unternehmungen u.ä. eingesetzt.
Mainframes haben üblicherweise einen ungleich höheren Datendurchsatz als Supercomputer.
Es soll auch ein paar moderne Ansätze geben, wo der Mainframe grosse Vorteile hat. Ich nehme, die VM Geschichte mit sehr vielen virtuellen Unix Maschinen gehört dazu. Da bin ich aber nicht genau im Bilde, was es sonst noch für Anwendungsfälle sein könnten.
Lilebror
2005-05-17, 21:09:38
Warum werden sie denn nur einmal eingeschaltet und quasi nicht wieder aus ? Fressen die im Anlaufen zu viel Strom so das die Kraftwerke bzw. das Lichtnetz überlastet werde/wird ? :confused:
Avalox
2005-05-17, 21:22:38
Na weil deren Aufgabe keine Unterbrechung erlaubt.
Je nach Auffassung, muss z.B. die Kontenverwaltung einer Bank immer verfügbar sein.
Woher stammt denn das Zitat?
Dieser Absatz steht in den heutigen 3Dcenter News:
Bei Golem hat man ein recht interessantes Interview mit dem Intel-Vize Pat Gelsinger in zwei Teilen geführt: Teil 1 und Teil 2. Insbesondere im letztgenannten Teil geht es stark um die Zukunftsaussichten mit MultiCore-Prozessoren (wobei die Aussage "vom Dual- zum Multi- zum Many-Core" schon andeutet, daß mit "Multi" letztlich sehr viele Cores gemeint sind) und auch die Probleme, welche diese vor allem auf Software-Seite mit sich bringen. Interessant war beispielsweise die Aussage, daß sowohl Microsoft- als auch Linux-Entwickler noch nicht wissen, wie sie für ein MultiCore-System ihr Betriebssystem vernünftig parallelisieren können. Es ist zwar einfach, den Support für dieserart viele Cores einzubauen, jedoch auf Betriebssystem-Ebene davon in der Performance zu profitieren, soll wohl nicht so einfach zu realisieren sein ...
GloomY
2005-05-19, 16:41:18
Die Aussage ist quatsch. Sowohl Windows als auch Linux unterstützen schon seit Ewigkeiten Multithreading.
Was wohl gemeint ist, ist das der Kernel selber nicht auf mehreren Cores läuft,Um genau zu sein läuft der Kern bereits auf mehreren Cores, wenn man eine SMP Maschine hat. Jedesmal, wenn es einen Interrupt bei einem der beiden Prozessoren gibt, kommt es zu einem Kerneintritt. Wenn das bei beiden Prozessoren gleichzeitig passiert, läuft der Kernel gleichzeitig auf zwei CPUs.
Was hier natürlich gemeint ist, ist dass so eine Abarbeitung eines Kernaufrufs weiterhin seperat auf einem Prozessor abgearbeitet wird.
[...] was aber auch nicht weiter schlimm ist.Eben ;) Es ergibt ja auch nicht viel Sinn hierbei den anderen Kern / CPU auch noch zu unterbrechen.
Leonidas
2005-05-21, 16:23:22
Es geht um die effiziente Auslastung der vielen Kerne. Dass man irgendwie viele Kerne nutzen kann steht ausser Frage.
Genau das ist gemeint, sorry wenn das Newsposting das nicht klar ausdrückt.
Bezüglich dieser Aussage vertraue ich dann im übrigen der Ausführung des Intel-Vizes. Wenn es diesbezüglich andere stichhaltige Argumentationen gibt, dann her damit.
Demirug
2005-05-21, 16:32:09
Um genau zu sein läuft der Kern bereits auf mehreren Cores, wenn man eine SMP Maschine hat. Jedesmal, wenn es einen Interrupt bei einem der beiden Prozessoren gibt, kommt es zu einem Kerneintritt. Wenn das bei beiden Prozessoren gleichzeitig passiert, läuft der Kernel gleichzeitig auf zwei CPUs.
Was hier natürlich gemeint ist, ist dass so eine Abarbeitung eines Kernaufrufs weiterhin seperat auf einem Prozessor abgearbeitet wird.
Eben ;) Es ergibt ja auch nicht viel Sinn hierbei den anderen Kern / CPU auch noch zu unterbrechen.
Ein großes Problem ist dabei aber das einige Betriebssysteme mit recht wenigen Syncronistationsobjekte im Kern arbeiten. Dadurch wird dann oft verhindert das mehrere CPU Kerne sich gleichzeitig im Kern aufhalten können.
Speicherverwaltung ist da ein typisches Beispiel.
Hat sich da nicht viel bei Linux 2.6 getan?
Um genau zu sein läuft der Kern bereits auf mehreren Cores, wenn man eine SMP Maschine hat. Jedesmal, wenn es einen Interrupt bei einem der beiden Prozessoren gibt, kommt es zu einem Kerneintritt. Wenn das bei beiden Prozessoren gleichzeitig passiert, läuft der Kernel gleichzeitig auf zwei CPUs.
Was hier natürlich gemeint ist, ist dass so eine Abarbeitung eines Kernaufrufs weiterhin seperat auf einem Prozessor abgearbeitet wird.
Eben ;) Es ergibt ja auch nicht viel Sinn hierbei den anderen Kern / CPU auch noch zu unterbrechen.
Bin zwar kein OS Hack - aber gerade Linux mit seinem Monolitischen Kern wird wohl schwer auf Multicore CPUs anpassbar sein.....
Windows hat mit seinem Nachrichten orientiertem Kern weitaus bessere Aussichten....
Meines Wissens war Beos das einzige (Mainstream) Betriebssystem, dessen Kernel selbst multithreaded war und sich selbst auf mehrere CPU's verteilen konnte.....
svenw
2005-05-21, 22:47:33
Welche BS Prozesse könnten denn davon profitieren? aber merkt man einen Unterschied zwischen einem 1GHz und einem 3 GHz System auf BS Ebene? Das Anwendungen schneller laufen ist klar, aber das nakte BS? Für simple Textverarbeitung reicht doch ein 1GHz System schon, wofür also mehr Rechenpower für das BS?
Bin zwar kein OS Hack - aber gerade Linux mit seinem Monolitischen Kern wird wohl schwer auf Multicore CPUs anpassbar sein.....Das hat doch nix mit dem monolithischen Kernel zu tun. Jetzt mal nichts durcheinander bringen.
Linux hat schon seit 2.0 SMP Support, das ist inzwischen sehr ausgereift.
Das hat doch nix mit dem monolithischen Kernel zu tun. Jetzt mal nichts durcheinander bringen.
Linux hat schon seit 2.0 SMP Support, das ist inzwischen sehr ausgereift.
Ja das stimmt - aber da der Kern monolitisch ist, läuft er nur auf einer CPU.
Aber andere Prozesse oder natürlich auch Threads kann der Kern auf andere CPU's oder auch Kerne verteilen...
Und was genau willst du im Kernel großartig Multithreaden?
Vielleicht mußt Du erst mal überlegen, was ein Betriebssytem Kernel überhaupt macht ......
Da kann man auch überlegen, was man in Threads verteilen kann....
Das weiß ich eigentlich. Und da fällt mir eben nix ein was man groß parallelisieren könnte bzw wo es sich überhaupt lohnt.
Hi Coda...noch so spät sich mit solchen schwierigen Fragen beschäftigen..... :smile:
Auch wenn ich etwas schreibe, dass Du schon weißt
Der Linux Kernel z.B in monolitisch...d.h. er ist im Grunde wie ein C Programm, dass immer linear weiterläuft.
Für bestimmte wichtige Dinge - wie Interrupt Behandlung - wird ein Kerneltrap
aufgeruften...also das Kernelprogamm wird einfach unterbrochen....
eine Interrupt Kernel Routine (ISR) ausgeführt..und dann das Kernel Programm weiter ausgeführt...
Wenn jetzt aber bestimmte Kernelteile in extra Prozessen laufen - und sich mit Nachrichten mitteilen was passiert.....kann der Teil der sich mit den ISR beschäftigt dies tun - des anderen Kernelprogrammen mitteilen - und so lange wie die ISR dauert...könnten die anderen Kernelprogramme etwas anders tun....was nicht mit dem Interrupt in Konflikt kommt....
NeoCream
2005-05-22, 09:45:49
Na weil deren Aufgabe keine Unterbrechung erlaubt.
Je nach Auffassung, muss z.B. die Kontenverwaltung einer Bank immer verfügbar sein.
Zero downtime bedeutet in der Realität nicht, dass die Maschine ständig am laufen ist. Der Prozentwert beträgt rund 99.98% oder so ähnlich.
Die Dinger gehen sehr wohl runter. Auch werden sie bei entsprechenden Software-Fixes kommplett abgeschaltet und dann neu gebootet(IOGEN). Wie jeder andere Rechner auch. Jedoch sind solche Einspielungen sehr selten.
Ausserdem bezieht sich das z/OS auf das Betriebsystem (Software) und nicht die eigentliche Maschine. Da auch ein z/OS nicht extrem stabil läuft, ergeben sich dann und wann Komplikationen und ein ganzes System taucht weg oder verklemmt sich.
Wer denkt, dass diese z/OS oder ähnliche Mainframe-Software rock-stable sind hat wohl noch nie in einer solchen Umgebung gearbeitet.
Demirug
2005-05-22, 09:46:15
Das weiß ich eigentlich. Und da fällt mir eben nix ein was man groß parallelisieren könnte bzw wo es sich überhaupt lohnt.
Einen Kernel Multicore fähig zu machen bedeutet ja nicht wie ich schon schrieb das man die anfallenden Arbeiten auf mehrer Kerne verteilt. Die Kunst dabei ist es zu verhindern das sich Kernelfunktionen gegenseitig blockieren wenn Anwendungen die Dienste des Kernels in Anspruch nehmen.
Ähnliches gilt dann im erweiterten Sinn auch für Betriebssystemfunktionen welche nicht im Kernel laufen und genauso für die Runtimes der Programmiersprachen. Vieles davon ist einfach nicht darauf ausgelegt gut mit Multicores zusammen zu arbeiten.
Exxtreme
2005-05-22, 10:35:23
Ja das stimmt - aber da der Kern monolitisch ist, läuft er nur auf einer CPU.
Aber andere Prozesse oder natürlich auch Threads kann der Kern auf andere CPU's oder auch Kerne verteilen...
Ein monolitischer Kernel sollte eigentlich keine Nachteile bezüglich Multithreading haben. :|
Oder ich sehe zumindest keinen Bereich wo ein Microkernel Vorteile hätte. Ein Microkernel wird wohl meist eh' langsamer sein als ein Monolithkernel weil da mehr Verwaltungsaufwand anfällt. Und da helfen mehrere CPUs auch nicht so richtig alsdass es Vorteile hätte ggü. einen Monolithkernel.
Demirug
2005-05-22, 10:45:37
Ein monolitischer Kernel sollte eigentlich keine Nachteile bezüglich Multithreading haben. :|
Oder ich sehe zumindest keinen Bereich wo ein Microkernel Vorteile hätte. Ein Microkernel wird wohl meist eh' langsamer sein als ein Monolithkernel weil da mehr Verwaltungsaufwand anfällt. Und da helfen mehrere CPUs auch nicht so richtig alsdass es Vorteile hätte ggü. einen Monolithkernel.
Ein Microkernel verhindert recht effektiv das man einen globalen Kernellock einbauen kann.
Einen zusätzlichen Verwaltungsaufand gibt es lediglich beim starten im Betrieb hat man nur einen zusätzlichen Kommunikationsaufwand der aber auch nur dadurch entsteht das die einzelnen Komponenten nicht direkt kommunizieren können und man deswegen über den verbleibenden Basiskern gehen muss. Das Problem kann man aber lösen indem man alles in einem Ring in einem Addressraum laufen lässt. Keine Sorge auch das bekommt man stabil sogar stabiler als einen monolitischen Kern mit klasischem Speicherschutzmodel. Da bei einem Mcrokernel Model auch alle Treiber eigene Prozesse sind können die ruhig mal abstürzen ohne das Gesamtsystem zu gefärden.
Bokill
2005-05-22, 12:44:15
Ich wollte noch eine Bemerkung zu den Ring-Ebenen machen.
Bislang war es ja so, dass bestimmte Bestandteile des Kernels in der höchsten Priorität liefen ... mit Vanderpool, Pacifica ist es eben nicht mehr (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=2902558#post2902558) der Fall. Die Virtualisierungsengine hat die höchste Instanz, und verschiebt gleichsam Teile des Betriebssystem in niederrangige Ebenen.
SUN Solaris 10 ist noch etwas anders gebaut, aber mit dieser Container Technologie kenne ich mich nicht aus. Softwareseitig findet aber jetzt schon länger ein Umdenken statt, welche Bestandteile in den jeweiligen Ringebenen der CPU-Bearbeitung gehören.
Mag zwar scheinbar wegführen (tut es aber eben nicht), und könnte so zur Zukunft der Multicore Betriebssysteme weiterhelfen ...
Bo(2005)
Das mit dem Ring1 gibt es ja heute schon für Linux und anderes
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/index.html
Da steht auch dass sie Windows mit HW Support (d.h. Pacifica/Vanderpool) unterstützen könnten im FAQ.
Bokill
2005-05-22, 13:55:55
Du erzählst mir nichts neues :D : Von hinten durch die Brust (http://www.planet3dnow.de/vbulletin/showthread.php?p=1881469#post1881469), The Xen virtual machine monitor (http://www.athlon.de/printthread.php?Board=UBB8&main=849849&type=post) ...
Ich denke nur, dass so etwas wie ein Umdenken in den OS-Schmieden stattfindet, das Umdenken ist noch lange nicht abgeschlossen ...
Bo(2005)
Ich frage mich ja ob sich Vanderpool und Pacifica überhaupt unterscheiden werden
GloomY
2005-05-23, 22:16:14
Einen Kernel Multicore fähig zu machen bedeutet ja nicht wie ich schon schrieb das man die anfallenden Arbeiten auf mehrer Kerne verteilt. Die Kunst dabei ist es zu verhindern das sich Kernelfunktionen gegenseitig blockieren wenn Anwendungen die Dienste des Kernels in Anspruch nehmen.Je nachdem, was die Anwendungen anfordern, sollte das doch möglich sein. Ein Page Fault und ein Syscall dürften sich doch nicht umbedingt gegenseitig stören. Die eine Anforderung braucht die Seitentabelle und eventuell den Pager mit der Festplatte und die andere vielleicht eine ganz andere Kernel-Komponente wie die Routinen für den TCP/IP Stack.
Schwierig wird es eben nur dann, wenn mehrere Prozessoren eine Komponente des Betriebssystems verwenden wollen, die nur seriell abgearbeitet werden kann (u.a. um die Korrektheit der internen Datenstrukturen zu gewährleisten).
Ein Microkernel verhindert recht effektiv das man einen globalen Kernellock einbauen kann.Ja, denn es gibt schlichtweg nicht mehr viel, was man im Kernel aufrufen kann. ;) Das ist leicht überspitzt formuliert, aber im Prinzip macht ein Mikrokernel doch hauptsächlich IPC.
Wenn zwei Prozessoren nun gleichzeitig eine Komponente des Betriebssystems benutzen wollen, frage ich mich, ob da ein Mikrokernel wirklich weiterhilft. Wenn die Komponente selbst nur seriell eine Anfrage nach der Anderen bearbeiten kann, wird doch auch hier einer der beiden Prozessoren warten müssen.
Einen zusätzlichen Verwaltungsaufand gibt es lediglich beim starten im Betrieb hat man nur einen zusätzlichen Kommunikationsaufwand der aber auch nur dadurch entsteht das die einzelnen Komponenten nicht direkt kommunizieren können und man deswegen über den verbleibenden Basiskern gehen muss. Das Problem kann man aber lösen indem man alles in einem Ring in einem Addressraum laufen lässt. Keine Sorge auch das bekommt man stabil sogar stabiler als einen monolitischen Kern mit klasischem Speicherschutzmodel. Da bei einem Mcrokernel Model auch alle Treiber eigene Prozesse sind können die ruhig mal abstürzen ohne das Gesamtsystem zu gefärden.Eine Frage dazu: Wie läuft das mit dem Speicherschutz genau ab? Dies ist eine absolut wichtige Anforderung an das korrekte Funktionieren von Multitasking Betriebssystemen. Durch das Wegfallen von seperaten Adressräumen pro Prozess muss man diese Problem doch irgendwie ander lösen...:conf2:
Konkret: Wenn an Adresse x Code oder Daten eines Prozesses liegen, wie verhindere ich (effizient), dass ein anderer Prozess nicht schreibend auf diese Speicherstelle zugreift?
Übrigends wird ein gemeinsamer Adressraum wohl nur bei 64 Bit Systemen realisierbar sein, oder? 32 Bit dürfte einfach zu klein sein...
Demirug
2005-05-23, 22:41:20
Ein bischen mehr als nur IPC macht ein Microkernel oft schon. Aber das ist immer eine Frage des Desgins. Wenn Anwendungen auf den gleichen Teil des OS wollen gibt es da natürlich schon Probleme. Aber auch da gibt es Tricks den Lock so kurz wie möglich zu halten.
Was den Speicherschutz angeht: http://channel9.msdn.com/ShowPost.aspx?PostID=68302
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.