Thema: SMP und die damit verbundenen Probleme

[erik.vikinger]

Hallo,

Die Pages landen ziemlich "spät" bis gar nicht im Frei-Pool. Die sind auch gar nicht das Problem, sondern das eine andere CPU auf Page A zugreift, da es so im TLB steht, aber inzwischen Page B an der virtuellen Adresse steht.

Richtig, genau das ist das Problem. Sorry, ich hatte mich in die physischen Pages verrannt. Du darfst den virtuellen Bereich erst dann als frei markieren wenn dieser sicher aus allen TLBs gelöscht ist! Erst danach ist es sicher das dieser virtuelle Bereich für was anderes benutzt wird.

Richtig, an Erfahrung mangelt es mir, besonders was das Programmieren von Anwendungen betrifft. Meine Programmiererfahrung beschränkt sich leider nur auf das OS Programmieren.

Es wurde hier ja schon mehrmals geschrieben, OS-Dev ist wirklich nicht der ideale Bereich um allgemeine Programmier-Erfahrung zu sammeln.

Am Bsp. einer Deadlock wüsste ich nicht wie ich zur Laufzeit prüfen könnte das einer vorliegt. Das gemeine am Deadlock ist doch, du kannst ja nicht wissen ob der Lock halt gerade in Benutzung ist und bald wieder freigegeben wird oder ob der Besitzer des Lock gerade versucht den Lock zu bekommen den man selber inne hat!

Du kannst für jede beteiligte Funktion ein enum bauen in dem der aktuelle Status (also der gerade ausgeführte Teil-Abschnitt der zugehörigen Funktion) drin ist, es dürfen nur bestimmte Kombinationen dieser Stati auftreten und alles andere ist ein Fehler. Diese Funktionen können bei einem SMP-System natürlich mehrmals parallel aus unterschiedlichen Kontexten aufgerufen werden so das Du diese enums dynamisch (inklusive der Call-History) erstellen musst (dafür könnte man einen statischen Pool nehmen der einfach nur groß genug sein muss um alle gültigen Kombinationen bei der gegebenen CPU-Anzahl aufzunehmen). Sowas zu implementieren macht zwar etwas Arbeit (und kostet in der Debug-Version auch einiges an Performance) aber es lohnt sich sehr wenn man einen Automatismus hat mit dem man die Korrektheit seiner Implementierung prüfen kann. Ich hab sowas mal gemacht und es hat mir sehr geholfen alle möglichen Fehler halb automatisiert zu finden.

Fairerweise muss man schon mal sagen, wer macht denn ne wirkliche Design-Phase (mal von dir und deiner Hardware abgesehen)?

Also diejenigen die wirklich wollen das ihr Projekt ein Erfolg wird machen das tatsächlich. Ich hab sowas schon in einigen Firmen erlebt und weil ich gelernt hab das gut geplant == halb geschafft ist mach ich das in Hobby-Projekten auch immer so. Bei einem Kleinprojekt wo vielleicht 3 Tage Programmierarbeit drin steckt plane ich natürlich keine 2 Wochen lang aber erst mal in Ruhe überlegen und auch schriftlich fixieren was eigentlich das konkrete Ziel ist schadet definitiv nicht.

Ich behaupte mal das selbst bei größeren Softwareprojekten nicht so viel vorher designt wird, sondern das dann alle drauflos programmieren und deswegen kommt es oft zu Problemen.

Wenn schlechte Programmierer und/oder dumme Manager an einem Projekt beteiligt sind kann das durchaus so enden, ich hab das leider auch schon im Berufsleben miterleben müssen.

Und ich als Hobbyprogrammieren/Anfänger werde mich bestimmt nicht vorher hinsetzen und ein Design anfertigen.

Dann ist Dein Projekt wohl bereits jetzt schon zum Scheitern verurteilt. Was denkst Du warum es all diese tollen Projekt-Management-Tools gibt? Ich selber benutze die zwar nicht, weil ich bisher immer mit einer sauberen Text-Beschreibung ausgekommen bin, aber die haben durchaus ihre Daseinsberechtigung.

weil ich mich mit Dingen beschäftigen würde, von denen ich keine Ahnung habe und ohne Praxis auch nie haben werde.

Deswegen sollte man ja auch erst mal mit kleinen Projekten anfangen und sich dann ordentlich hocharbeiten.

Auch weiß ich nicht ob man je die Möglichkeit braucht das man eine IPI Nachricht an genau eine CPU (und eine bestimme) schicken können muss.

Selbst "alle außer die aktuelle" ist schon ein recht konkretes Ziel, aber selbst das kann ich auf meiner Plattform nicht umsetzen (zumindest hab ich bis jetzt keinen Mechanismus für derartiges vorgesehen).

Wenn du den Kernel mit einem GIANT_LOCK schützt brauchst du nichtmal dafür nen unterbrechbaren MikroKernel.

Also dass das keine intelligente Option ist wissen wir doch bereits alle.

hat denn die NMI Variante irgendwelche Nachteile?

Innerhalb eines NMI-Handlers kannst Du quasi keine Funktionen des restlichen Kernels nutzen, weil die ja alle durch einen NMI unterbrochen werden können und daher auch in kritischen Zuständen sein können.


Grüße
Erik

[FlashBurn]

Du darfst den virtuellen Bereich erst dann als frei markieren wenn dieser sicher aus allen TLBs gelöscht ist! Erst danach ist es sicher das dieser virtuelle Bereich für was anderes benutzt wird.

Darum muss ich mich jetzt nicht mehr kümmern bzw. kann es ignorieren. Denn der NMI wird sofort bearbeitet.

Es wurde hier ja schon mehrmals geschrieben, OS-Dev ist wirklich nicht der ideale Bereich um allgemeine Programmier-Erfahrung zu sammeln.

Sorry, aber dem kann ich nicht zustimmen. Mir wurde bereits vor 10Jahren in einer Newsgroup gesagt, was ich kann und was nicht und auch das hat sich hinterher als falsch erwiesen (ich wollte Assembler lernen indem ich nen Assembler programmiere und bin verdammt weit gekommen). Ist alles ne Frage der Hartnäckigkeit und des Willens.
Problem ist halt meistens nur, das anstatt sich selbst damit zu beschäftigen die meisten eher Copy&Paste machen, aber ich war schon immer jemand der lieber alles selbst macht (das hat natürlich auch Nachteile, vorallem in der reallen Welt ).

Du kannst für jede beteiligte Funktion ein enum bauen in dem der aktuelle Status (also der gerade ausgeführte Teil-Abschnitt der zugehörigen Funktion) drin ist, es dürfen nur bestimmte Kombinationen dieser Stati auftreten und alles andere ist ein Fehler. Diese Funktionen können bei einem SMP-System natürlich mehrmals parallel aus unterschiedlichen Kontexten aufgerufen werden so das Du diese enums dynamisch (inklusive der Call-History) erstellen musst (dafür könnte man einen statischen Pool nehmen der einfach nur groß genug sein muss um alle gültigen Kombinationen bei der gegebenen CPU-Anzahl aufzunehmen).

Ich lese in dem ganzen Text nur Bahnhof

Also diejenigen die wirklich  wollen das ihr Projekt ein Erfolg wird machen das tatsächlich. Ich hab sowas schon in einigen Firmen erlebt und weil ich gelernt hab das gut geplant == halb geschafft ist mach ich das in Hobby-Projekten auch immer so.

Das setzt aber vorraus dass das jemand macht der Erfahrung hat. Wenn du keine Ahnung von den Anwendungen hast (so wie ich) und dein OS designst dann wirst du an irgendeinem Punkt feststellen dass das Design so nicht funktioniert und/oder unvollständig ist.
Ich mache mir auch vorher nen Kopf, aber ich schreibe das nicht auf oder setze mich hin mit dem Ziel, jetzt machst du mal ein Design fertig (so funktoniert das mit den guten Ideen eh nicht).

Ich weiß nicht wieviel Erfahrung du mit dem Designen von Schaltungen hast, aber ich behaupte mal du wirst auch die eine oder andere Designschwäche erst finden wenn dann alles läuft.

@Offtopic

Hast du eigentlich vor nen Emulator für dein System zu schreiben? Denn so könntest du z.B. Designschwächen schon vorher feststellen.

@Ontopic

Dann ist Dein Projekt wohl bereits jetzt schon zum Scheitern verurteilt.

Das ist einfach zu Allgemein! Denn ich sage mal ich bin schon verdammt weit gekommen (und wäre schon weiter wenn ich nicht oft Motivationsprobleme hätte) ohne das ich mein OS designt habe. Was richtig ist, das ich mir mit einigen Überlegungen den einen oder anderen Rewrite hätte sparen können, aber auch die waren im Nachhinein wichtig und gut. Denn man lernt am besten aus Fehlern.

Was denkst Du warum es all diese tollen Projekt-Management-Tools gibt?

Um viele Leute zu synchronisieren und einen bestimmten Zeitplan einhalten zu können?! Ich lerne das ja auch alles in der Uni, aber für ein ein Mann-Hobby-Projekt ist ein PMT wirklich sehr übertrieben. Ich arbeite an der Sache wo ich gerade Lust drauf habe und nicht auf irgendeinen Milestone hinaus. Auch irgendwelche Features werden halt dann implementiert wenn ich sie brauche oder über eine interessante Idee gestolpert bin die ich umsetzen will.
Was ich mal benutzen sollte, wäre ein RVS.

Deswegen sollte man ja auch erst mal mit kleinen Projekten anfangen und sich dann ordentlich hocharbeiten.

Sorry, halte ich was das Hobby betrifft auch für quatsch. Im Berufsleben ja, wo es um Leben und Tod (sinnbildlich) geht.
Ich habe mir als großes Ziel gesetzt nen OS zu schreiben. Alle sagen schaffst du eh nicht. Wenn ich dann irgendein kleineres Ziel erreicht habe (z.B. Bootloader, Kernel kann Speicher allokieren usw.) dann freue ich mich umso mehr, aber zu sagen, nur weil man sich ein verdammt hohes Ziel gesetzt hat, das man es nicht erreicht oder das es nichts bringt ist falsch!

Innerhalb eines NMI-Handlers kannst Du quasi keine Funktionen des restlichen Kernels nutzen, weil die ja alle durch einen NMI unterbrochen werden können und daher auch in kritischen Zuständen sein können.

Ist klar und deswegen überlege ich auch, die Rendevouz-Funktionalität wieder in einen normalen Int auszulagern, aber solange ich den nur für das eine Mal zum Synchronisieren nehme, ist das noch kein Problem.

Was mir noch eingefallen ist, nen NMI kann man auch wunderbar dafür nutzen um Deadlocks zu beheben (da wird ja dran geforscht, weiß nicht ob da schon was bei rausgekommen ist?).

[erik.vikinger]

Hallo,

Es wurde hier ja schon mehrmals geschrieben, OS-Dev ist wirklich nicht der ideale Bereich um allgemeine Programmier-Erfahrung zu sammeln.

Sorry, aber dem kann ich nicht zustimmen.

Ich habe doch extra geschrieben "nicht ideal" und dem wirst Du doch nicht wirklich widersprechen wollen? Es gibt auf jeden Fall einfachere Projekte an denen man üben und lernen kann, das Problem bei OS-Dev sind die vielen HW-Sachen und sonstigen LowLevel-Sachen die zu den normalen Programmierproblemen noch dazu kommen. Niemals würde ich behaupten das man nicht von 0 auf ein funktionsfähiges OS kommen kann, es ist nur nicht der ideale Weg und man braucht dafür eine Menge Durchhaltevermögen weil die Lernkurve auf diesem Weg nicht nur ziemlich steil sondern auch ziemlich lang ist.

Ich lese in dem ganzen Text nur Bahnhof

Dann ließ noch mal, es geht darum das Deine Funktionen mitloggen was sie tun so das Du zum Zeitpunkt eines Deadlock genau sagen kannst was los war in Deinem Kernel. Außerdem kann man damit erkennen wenn 2 Funktionen an die selbe Ressource wollen aber sich gegenseitig blockieren.

Das setzt aber vorraus dass das jemand macht der Erfahrung hat.

Klar setzt gutes Projekt-Management Erfahrung voraus, auch deswegen der Tipp sich erst mal an nicht ganz so komplexen Projekten zu üben. Ich will nicht sagen das man ohne Erfahrung definitiv kein Projekt ordentlich hin bekommt aber es erleichtert die Sache ungemein und es erspart einem ne Menge Frust wenn man bestimmte Probleme schon im voraus erkennt bevor man in der Sch.... sitzt.

Wenn du keine Ahnung von den Anwendungen hast (so wie ich) und dein OS designst dann wirst du an irgendeinem Punkt feststellen dass das Design so nicht funktioniert und/oder unvollständig ist.

Das kann einem sogar mit der besten Planung passieren aber mit einer guten Planung ist es signifikant unwahrscheinlicher das man in so eine Sackgasse gerät.

Ich mache mir auch vorher nen Kopf, aber ich schreibe das nicht auf oder setze mich hin mit dem Ziel, jetzt machst du mal ein Design fertig (so funktoniert das mit den guten Ideen eh nicht).

Ich will Dich doch nicht dazu überreden erst mal 5 Jahre lang nur zu planen, ich versuche Dir nur zu erklären das eine strukturierte Arbeitsweise vieles erleichtert. Klar wird man auch viele Ideen spontan umsetzen wollen (mach ich auch oft) aber auch hier macht sich eine gute Projektplanung bezahlt weil man so recht schnell nachlesen kann um zu prüfen ob die aktuelle Idee irgendwo Probleme verursachen könnte.

Ich weiß nicht wieviel Erfahrung du mit dem Designen von Schaltungen hast, aber ich behaupte mal du wirst auch die eine oder andere Designschwäche erst finden wenn dann alles läuft.

Ich erlebe es selbst bei Schaltungen von Profis, mit über 20 Jahren Erfahrung, das längst nicht jede davon auf der ersten Platinen-Revision wie gewünscht funktioniert. So ist das eben in der realen Welt.

Hast du eigentlich vor nen Emulator für dein System zu schreiben? Denn so könntest du z.B. Designschwächen schon vorher feststellen.

Ja ich schreibe einen Emulator, der kann sogar schon ein paar Befehle, und auf echte FPGAs will ich frühestens umsteigen wenn ich einen zufriedenstellenden Compiler hab damit ich mir sicher sein kann das mein Befehlssatz keine Probleme mehr hat.

Und ich als Hobbyprogrammieren/Anfänger werde mich bestimmt nicht vorher hinsetzen und ein Design anfertigen.

Dann ist Dein Projekt wohl bereits jetzt schon zum Scheitern verurteilt.

Das ist einfach zu Allgemein!

Sorry, das hätte ich so nicht formulieren sollen. Trotzdem kann ich Deine Ablehnung gegenüber einer ordentlichen Planung nicht nachvollziehen, aber nach 10 Jahren im Projekt-Geschäft ist das sicherlich normal. Ich hab einfach zu viele Projekte miterlebt die von Stümpern (als Programmierer aber auch als Manager) in den Sand gesetzt wurden, oft aus dem Grund das diese Leute es nicht geschafft haben ihre Aufgaben anständig zu strukturieren, als das ich diesen Weg noch für gut heißen kann. Ich will damit nicht sagen das Du nichts hinbekommst, ich will nur zum Ausdruck bringen das Du es Dir damit meiner persönlichen Meinung nach schwerer machst als nötig. Mit einer guten Planung wärst Du jetzt vielleicht schon etwas weiter.

Ich arbeite an der Sache wo ich gerade Lust drauf habe und nicht auf irgendeinen Milestone hinaus.

Das ist aber nicht immer zielführend, ich würde auch gerne heute schon am ALR oder anderen tollen Dingen rumprogrammieren aber es geht einfach noch nicht weil die nötige Basis dafür noch fehlt. Stattdessen schreibe ich meine Ideen auf und setze sie später um, auf diese Weise vergesse ich auch nichts und wenn eine Idee dran ist kann ich noch mal schnell prüfen ob sie sich noch mit dem aktuellen Design verträgt.

Deswegen sollte man ja auch erst mal mit kleinen Projekten anfangen und sich dann ordentlich hocharbeiten.

Sorry, halte ich was das Hobby betrifft auch für quatsch.

Warum? Das musst Du mir mal erklären. Bist Du wirklich immer der Meinung das man im Hobby gleich ganz oben einsteigen sollte?

aber zu sagen, nur weil man sich ein verdammt hohes Ziel gesetzt hat, das man es nicht erreicht oder das es nichts bringt ist falsch!

Natürlich soll man sich auch ruhig hohe Ziele stecken aber man sollte dabei im Rahmen bleiben.

  "Wer den Himmel erreichen will muss sich schon mal nach den Sternen recken."

Was mir noch eingefallen ist, nen NMI kann man auch wunderbar dafür nutzen um Deadlocks zu beheben (da wird ja dran geforscht, weiß nicht ob da schon was bei rausgekommen ist?).

Hä, wovon schreibst Du da? Ein NMI ist doch kein Heilmittel.


Grüße
Erik

[FlashBurn]

Mit einer guten Planung wärst Du jetzt vielleicht schon etwas weiter.

Mein Problem/Vorteil ist das ich bisher keine richtige Planung (im klassischem Sinne) gebraucht habe und damit bisher ganz gut gefahren bin.
Und die Planung ist ja nicht mein Problem, sondern die Motivation (ich langweile mich schnell ).

Das ist aber nicht immer zielführend, ich würde auch gerne heute schon am ALR oder anderen tollen Dingen rumprogrammieren aber es geht einfach noch nicht weil die nötige Basis dafür noch fehlt.

Genau das ist auch mein Problem, die Basis. Ich müsste halt ne C-Library portieren bzw. zum Großteil neuschreiben, habe aber einfach keine Lust dazu. Deswegen werkle ich oft am Kernel rum und versuche noch mehr zu verbessern/verschlimmbessern

Stattdessen schreibe ich meine Ideen auf und setze sie später um, auf diese Weise vergesse ich auch nichts und wenn eine Idee dran ist kann ich noch mal schnell prüfen ob sie sich noch mit dem aktuellen Design verträgt.

Nennt man das Planung und Design, weil dann mach ich das doch Ich habe auch ne Liste wo Ideen drinstehen, die mir mal eingefallen sind und ab und zu guck ich rein und die Liste wird halt aktualisiert.

Warum? Das musst Du mir mal erklären. Bist Du wirklich immer der Meinung das man im Hobby gleich ganz oben einsteigen sollte?

Nein das nicht, aber mich nervt diese Einstellung derjenigen die schon was auf dem Kasten haben (meine Erfahrung ist dass das weltweit, also in den Foren in denen ich so verkehre) zu den Anfängern immern sagen, kannst du eh nicht schreib erstmal nen HelloWorld.

Ich habe das Programmieren nur für das Ziel gelernt ein OS schreiben zu wollen.

Natürlich soll man sich auch ruhig hohe Ziele stecken aber man sollte dabei im Rahmen bleiben.

Meine Erfahrung ist halt das zu hohe (ja ich meine das man sie wahrscheinlich nie erreicht) Ziele durchaus gut sind. Es motiviert oft wesentlich mehr und man freut sich über jedes kleine Zwischenziel mehr als wenn man sagt, versuch ich halt was kleines.
Das ist aber ne Einstellungssache, für mich ist durchaus sinnvoll ein Ziel zu haben was man nicht unbedingt erreichen kann. Denn daraufhin muss man viel härter hinarbeiten als wenn man sich kleinere Ziele setzt und so kommt man öfter schneller zu einem Erfolg und meistens sogar zu einem Erfolg der besser/höher ist als kleinere Ziele.

Hä, wovon schreibst Du da? Ein NMI ist doch kein Heilmittel.

Richtig. Mir ging es darum, dass du eine Deadlock gar nicht (selbst wenn du wüsstest wie) beheben kannst wenn die Ints aus sind, weil du die CPU ja nicht unterbrechen kannst, aber mit nem NMI wird das möglich. So kannst du jeder "festgefahrenen" CPU anderen Code "aufzwingen".

Man könnte eine Art Watchdogtimer in Software implementieren und wenn eine CPU innerhalb einer bestimmten Zeitspanne nicht reagiert wird sie per NMI "neugestartet".

[Svenska]

Also wenn ich irgendwo was lese/höre, was mir auf Anhieb gefällt und ich noch implmentieren müsste, dann greif ich mir Stift&Zettel und schreibe mir das Wesentliche davon auf.

Das nehme ich während der Implementation als Stichwortzettel. Außerdem schreibe ich neben dem Programmieren eine kleine Dokumentation. Dadrin steht nicht-offensichtliches Verhalten (z.B. dass eine Funktion nicht unbedingt jeden Parameter einzeln prüft), aber auch die Interfaces. Sinnvoll sind bei größeren Dingen Blockdiagramme (auf dem Papier), mehr mache ich meistens auch nicht.

Hab ich mir angewöhnt, als ich irgendwann in der Schule bei nem etwas größeren Projekt mal den Überblick komplett verloren habe.

Wenn du dir ohne Bildschirm vorher ein paar Designgrundlagen aufschreibst und danach dann implementierst, merkst du die Logikfehler spätestens während der Implementation und kannst den Teil teilweise als Blackbox betrachten und anders lösen, ohne den Rest wegwerfen zu müssen. Außerdem baust du in der Regel dann sauberere Schnittstellen - vielleicht nicht elegant oder praktisch, aber sauber.

Das Gesamtsystem überarbeiten kann man später immernoch, wenn man an das eine oder andere nicht gedacht hat. Ich schätze dich aber so ein, dass du dir vorher überlegst, welche Fähigkeiten dein Interface braucht, also wird es im ersten Anlauf zumindest funktionieren.

Gruß

[erik.vikinger]

Hallo,

Mein Problem/Vorteil ist das ich bisher keine richtige Planung (im klassischem Sinne) gebraucht habe und damit bisher ganz gut gefahren bin.

Dann hast Du wohl wirklich noch nicht vieles gemacht das über Hello-World deutlich hinaus geht.

Und die Planung ist ja nicht mein Problem, sondern die Motivation (ich langweile mich schnell ).

Da hast Du allerdings ein sehr ernstes Problem.

Stattdessen schreibe ich meine Ideen auf und setze sie später um, auf diese Weise vergesse ich auch nichts und wenn eine Idee dran ist kann ich noch mal schnell prüfen ob sie sich noch mit dem aktuellen Design verträgt.

Nennt man das Planung und Design, weil dann mach ich das doch

Also ich mache schon einiges mehr als nur eine ToDo-Liste, die ist nur ein Teil davon. Ich spezifiziere z.B. alle Schnittstellen und Protokolle möglichst gründlich und für meine Plattform arbeite ich an einer richtigen Dokumentation.

zu den Anfängern immern sagen, kannst du eh nicht schreib erstmal nen HelloWorld.

Auf die Gefahr hin das Du mich jetzt nicht mehr magst aber das ist ein sehr guter Hinweis. Ein echter Anfänger sollte wirklich nicht gleich ganz oben einsteigen, die Wahrscheinlichkeit das er auf seiner blutigen Nase landet ist einfach zu hoch. Natürlich muss man nicht erst 100 Projekte mit langsam ansteigendem Schwierigkeitsgrad erfolgreich absolviert haben um dann irgendwann mal oben anzukommen, das darf auch in größeren Schritten passieren, aber von 0 auf 100 in nur einem Schritt geht zu mehr als 99% nicht gut.

Ich habe das Programmieren nur für das Ziel gelernt ein OS schreiben zu wollen.

Ich kann das nicht wirklich beurteilen aber mein Bauch sagt mir dass das nicht gut ist.

Meine Erfahrung ist halt das zu hohe (ja ich meine das man sie wahrscheinlich nie erreicht) Ziele durchaus gut sind. Es motiviert oft wesentlich mehr und man freut sich über jedes kleine Zwischenziel

Aber zu hohe Ziele an denen man ständig scheitert sind nicht gerade Motivierend. Die Ziele sollten ruhig fordernd sein aber nicht überfordernd. Wo man da die Grenze zieht ist natürlich sehr individuell.

mehr als wenn man sagt, versuch ich halt was kleines.

Zu kleine Ziele sind natürlich auch Mist, da fehlt dann einfach das gute Gefühl eine Herausforderung geschafft zu haben.

Mir ging es darum, dass du eine Deadlock gar nicht (selbst wenn du wüsstest wie) beheben kannst wenn die Ints aus sind, weil du die CPU ja nicht unterbrechen kannst, aber mit nem NMI wird das möglich. So kannst du jeder "festgefahrenen" CPU anderen Code "aufzwingen".

Einen Deadlock kann man überhaupt gar nicht beheben. Die Funktionen haben doch die INTs deaktiviert weil irgendwelche Strukturen in kritischen bzw. ungültigen Zuständen sind, das kann man nicht beheben indem man diese Funktionen einfach abwürgt und anderen Code ausführt. Außerdem wurden diese Funktionen ja mit einem Grund aufgerufen, der ist schließlich nicht weg. Man kann zwar vielleicht ein malloc abbrechen aber der Prozess der Speicher haben wollte ist trotzdem noch da und erwartet eine Antwort.

Man könnte eine Art Watchdogtimer in Software implementieren und wenn eine CPU innerhalb einer bestimmten Zeitspanne nicht reagiert wird sie per NMI "neugestartet".

Watchdog in SW geht nicht, was ist wenn die SW in ner Endlosschleife gefangen ist? Ein Watchdog muss immer als eigenständige und unabhängige Hardware implementiert werden.


Grüße
Erik

[Svenska]

Man könnte eine Art Watchdogtimer in Software implementieren und wenn eine CPU innerhalb einer bestimmten Zeitspanne nicht reagiert wird sie per NMI "neugestartet".

Watchdog in SW geht nicht, was ist wenn die SW in ner Endlosschleife gefangen ist? Ein Watchdog muss immer als eigenständige und unabhängige Hardware implementiert werden.

Watchdog in Software geht, ist aber nicht so universell einsetzbar. Insbesondere, wenn der Kernel auf mehreren CPUs läuft, ist es möglich, dass eine CPU die festhängenden CPUs neu startet.

Das ist aber Symptombehebung, nicht Ursachenbehebung. Außerdem verlierst du durch sowas jegliches Vertrauen in dein System (Zuverlässigkeit: der Deadlock mag weg sein, aber du hast dann Zombies im System) und jegliche Echtzeitfähigkeiten (CPU-Neustart ist ungeplant). Mach es trotzdem nicht.

[erik.vikinger]

Hallo,

Das ist aber Symptombehebung, nicht Ursachenbehebung. Außerdem verlierst du durch sowas jegliches Vertrauen in dein System

Exakt!
Ein Watchdog suggeriert dass das System noch läuft obwohl es eigentlich fehlerhaft ist und nicht mehr funktionieren kann. Das ist vielleicht in einem medizinischen Gerät zulässig wo das Leben des Patienten wichtiger als der Speicherverbrauch o.ä. ist, aber in einem normalen OS ist ein Watchdog völliger Blödsinn. Auch bei SW für Atomkraftwerke geht man auf diese Art und Weise an die Entwicklung aber dafür ist keiner von uns ausreichend qualifiziert!


Grüße
Erik

[FlashBurn]

Dann hast Du wohl wirklich noch nicht vieles gemacht das über Hello-World deutlich hinaus geht.

In dem Sinne genau 2 Projekte, nen Assembler in Assembler und nen OS (nennen wir es bisher Kernel) in Asm (komplett) und in C.

Auf die Gefahr hin das Du mich jetzt nicht mehr magst aber das ist ein sehr guter Hinweis.

Ich bin jemand der Kritik sehr gerne austeilt, aber (und genau deswegen mögen mich soviele Leute nicht) ich kann auch viel Kritik einstecken und nehme mir die oft sogar zu Herzen.

Ein echter Anfänger sollte wirklich nicht gleich ganz oben einsteigen, die Wahrscheinlichkeit das er auf seiner blutigen Nase landet ist einfach zu hoch. Natürlich muss man nicht erst 100 Projekte mit langsam ansteigendem Schwierigkeitsgrad erfolgreich absolviert haben um dann irgendwann mal oben anzukommen, das darf auch in größeren Schritten passieren, aber von 0 auf 100 in nur einem Schritt geht zu mehr als 99% nicht gut.

Naja, meine Erfahrung ist halt das man immer gesagt bekommt was man alles nicht kann und jeder Pädagoge wird dir sagen wie schlecht und falsch das ist.

Auch ein OS kann man auf sinnvolle kleine "Projekte" runterbrechen. Ich sage mal mir hat das Programmieren in Asm sehr gut geholfen, weil ich so weiß wie ein Stack und eine Hochsprache funktioniert und so viele Seiteneffekte verstehe, wo andere dran scheitern. Obowhl ich gerade auch eine Sache gelernt habe, die mir vorher nicht bekannt war (Rückgabe von lokal erzeugter struct).

Ich kann das nicht wirklich beurteilen aber mein Bauch sagt mir dass das nicht gut ist.

Warum nicht? Wäre ungefähr so, als wenn du Programmieren gelernt hast, weil du (irgendwann) ein Spiel schreiben willst.
Das ist wie lesen lernen um ein interessantes Buch lesen zu können. Sehe ich jetzt nichts falsches/schlechtes dran.

Du hast halt ein Ziel und musst halt einiges dafür lernen, in dem Fall ist halt das Programmieren "nur" etwas was man braucht um sein Ziel zu erreichen.

Die Ziele sollten ruhig fordernd sein aber nicht überfordernd. Wo man da die Grenze zieht ist natürlich sehr individuell.

Das hat was damit zu tun wie man mit Niederlagen umgehen kann. Ich bin eigentlich ganz gut darin Niederlagen in Siege zu verwandeln

Um mal ein Bsp. zu bringen, du nimmst dir halt vor nen 10km Lauf in einer bestimmten Zeit zu schaffen, trainierst wie blöde dafür und verfehlst dann dein Ziel, bist aber deutlich besser als noch das Jahr davor und ich behaupte jetzt wenn du dir ne wesentlich schlechtere Zeit vorgenommen hättest, wo du denkst ach das schaff ich schon, dann hättest du viel weniger erreicht, weil du nicht so hart trainiert hättest.

Aber wie du schon sagtest das ist sehr individuell.

Einen Deadlock kann man überhaupt gar nicht beheben.

Das ist so nicht richtig. Man muss halt nur einer der beiden Parteien den Lock entziehen (was auch heißen kann das der Prozess terminiert wird).

Es gibt da jedenfalls Überlegungen wie man solche Probleme zufriedenstellend lösen kann.

Das ist aber Symptombehebung, nicht Ursachenbehebung.

Also das was von der Politik in Dtl gemacht wird, kann doch so schlecht nicht sein

[erik.vikinger]

Hallo,

nen Assembler in Assembler

Du hast einen Assembler in Assembler programmiert? Respekt, ich benutze dafür lieber C++. Der Aufwand, sowas wie Labels auflösen und Sectionen verwalten, in Assembler zu machen wäre mir deutlich zu groß. Ich vermute mal das Du einen recht einfachen Assembler (also nicht was besseres als Two-Pass) ohne die Unterstützung für linkbare Object-File-Formate programmiert hast.

Ich bin jemand der Kritik sehr gerne austeilt, aber (und genau deswegen mögen mich soviele Leute nicht)

Mich mögen die meisten deswegen, und wegen der Tatsache das es mir nicht immer gelingt die Kritik in leicht verdauliche Sätze zu verpacken, auch nicht besonders.

ich kann auch viel Kritik einstecken und nehme mir die oft sogar zu Herzen.

Das ist nicht immer leicht aber sehr wichtig.

Naja, meine Erfahrung ist halt das man immer gesagt bekommt was man alles nicht kann und jeder Pädagoge wird dir sagen wie schlecht und falsch das ist.

Man darf den Menschen nicht nur negatives sagen aber man sollte auch ehrlich sagen können was man nicht kann. Ich hab z.B. noch nie ein Platinen-Layout für ein Chip mit BGA-Gehäuse gemacht. Der FPGA der mir momentan vorschwebt hat fast 2000 Pins und ist damit deutlich mehr als eine kleine Anfängerübung. Ich weiß ganz genau das ich für mein Projekt an dieser Stelle Unterstützung durch einen Profi benötige, das ist einfach zu schwer als das man sagen könnte "ich pack das schon irgendwie". Bis ich an diesen Punkt mit meinem Projekt komme (also frühestens nächstes Jahr, wohl eher übernächstes Jahr) muss ich das entweder selber gelernt haben (in mehreren nicht zu großen Schritten, vielleicht ergibt sich das ja im Berufsleben) oder ich benötige jemanden der mir hilft.

Das ist wie lesen lernen um ein interessantes Buch lesen zu können. Sehe ich jetzt nichts falsches/schlechtes dran.

Das ist ein guter Vergleicht. Wenn Du wirklich erst lesen lernen willst (es also nicht vorher kannst) nimmst Du dann ein Buch von z.B. Friedrich Nietzsche oder lieber eines speziell für Leseanfänger (Kinder)?

Du hast halt ein Ziel und musst halt einiges dafür lernen, in dem Fall ist halt das Programmieren "nur" etwas was man braucht um sein Ziel zu erreichen.

Richtig, so wie platinenlayouten etwas ist das ich wohl für mein Projekt erlernen muss.

Einen Deadlock kann man überhaupt gar nicht beheben.

Das ist so nicht richtig.

Doch das ist richtig. Eine echte Lösung gibt es für Deadlocks nicht.

Man muss halt nur einer der beiden Parteien den Lock entziehen (was auch heißen kann das der Prozess terminiert wird).

Und wie soll bestimmt werden welcher der beteiligten der Verlierer ist? Was ist mit Datenstrukturen die gerade in einem ungültigen Zustand sind?

Es gibt da jedenfalls Überlegungen wie man solche Probleme zufriedenstellend lösen kann.

Die würde ich gerne mal sehen.

Also das was von der Politik in Dtl gemacht wird, kann doch so schlecht nicht sein

Also wenn Du unsere Politiker zum Vorbild nimmst dann ist Dir wirklich nicht mehr zu helfen.


Grüße
Erik

[FlashBurn]

Ich vermute mal das Du einen recht einfachen Assembler (also nicht was besseres als Two-Pass) ohne die Unterstützung für linkbare Object-File-Formate programmiert hast.

Richtig. Ich war gerade dabei nen mathematischen Parser hinzuzufügen, aber da ist mir dann meine HDD abgeraucht und ich habe das Projekt begraben, es gibt sogar noch alte Sources auf Sourceforge.net, aber die sind wirklich alt. Denn ich hatte dann nen größeren rewrite begonnen und habe das nicht mehr hochgeladen (leider, im Nachhinein). Das ganze habe ich sogar unter DOS (also der Assembler lief unter DOS) gemacht, was nicht gerade sehr hilfreich war

Ich würde mich sogar wieder daran wagen, aber da ich kein großer Fan (eventuell nur noch nicht) von C++ bin, würde ich das in C machen.

Wäre direkt was womit ich mich jetzt beschäftigen könnte

aber man sollte auch ehrlich sagen können was man nicht kann.

Wenn dir andere aber sagen was du nicht kannst benutzen sie meist ein Wort was ich da nicht haben möchte und das lautet "nie"!

Wenn Du wirklich erst lesen lernen willst (es also nicht vorher kannst) nimmst Du dann ein Buch von z.B. Friedrich Nietzsche oder lieber eines speziell für Leseanfänger (Kinder)?

Ja und nein. Ich werde mir bestimmt nicht erst Kinderbücher auf Englisch durchlesen nur weil ich nen Roman lesen möchte (wie gesagt ich würde das nicht machen). Ich setze mich dann halt mit nem Wörterbuch hin und die ersten (vielen) Seiten dauert es halt länger, aber es wird halt immer besser und besser und du wirst so Dinge lernen (vorallem schneller lernen) die du durch Kinderbücher nie gelernt hätttest.

Der FPGA der mir momentan vorschwebt hat fast 2000 Pins

Ich habe da keine Ahnung von, aber wieso hat der soviele Pins? Soll das nur die CPU repräsentieren oder mehr?

Und wie soll bestimmt werden welcher der beteiligten der Verlierer ist?

Ne Münze werfen Ich weiß es auch nicht, nur das ich sowas mal irgendwo gelesen habe (könnte auch im Zusammenhang mit Datenbanken gewesen sein).

Also wenn Du unsere Politiker zum Vorbild nimmst

Dann würde ich ja kein neues OS programmieren sondern die Nachteile der vorhanden umgehen (und neue schaffen)

[Svenska]

Die meisten Pins in einem FPGA sind frei programmierbar. Hat man viele, kann man viel damit machen - so einfach ist das. Außerdem haben große FPGAs (was die Logikzellen angeht) fast immer auch viele Pins.

Deadlocks kann man nicht beheben. Du kannst dem einen Prozess eventuell das Lock entziehen (womit du mit Gewalt das Locking nutzlos machst - wozu locken, wenn das Lock vom OS entzogen werden kann?), aber der übrig bleibende Scherbenhaufen ist unter Umständen nicht mehr reparierbar.

Wenn im Linux-Kernel ein Kernelmodul abstürzt/oopst, dann wirst du auch im Log darauf hingewiesen, dass unter Umständen irgendwelche Listen jetzt kaputt sind und du doch lieber neustarten sollst, ehe du silent corruption kriegst. Ich stell mir das übrigens gerade wunderbar vor, wenn dein HDD-Treiber so aus einem Deadlock gerissen wird und der Festplattencontroller nun mit einer nicht vorgesehenen Befehlssequenz befüttert wird.

Dann nutzt die sauberste FS-Implementation nichts mehr.

Deadlocks sind "dead". No rescurrection possible.

Gruß

[erik.vikinger]

Hallo,

Wenn dir andere aber sagen was du nicht kannst benutzen sie meist ein Wort was ich da nicht haben möchte und das lautet "nie"!

Okay, das ist natürlich ein böses Wort das man in diesem Zusammenhang nie verwenden sollte.

Ja und nein. Ich werde mir bestimmt nicht erst Kinderbücher auf Englisch durchlesen nur weil ich nen Roman lesen möchte (wie gesagt ich würde das nicht machen).

Du hattest vorhin vom lesen lernen (also im Sinne von Analphabeten) geschrieben und nicht davon eine Fremdsprache zu erlernen. Bitte bleibe beim Thema!

Ich habe da keine Ahnung von, aber wieso hat der soviele Pins? Soll das nur die CPU repräsentieren oder mehr?

Ich muss die FPGAs in den Gehäusen kaufen die die Hersteller vorsehen und wenn es eine spezielle Kombination an Features eben nur in einem bestimmten Gehäuse gibt dann hab ich nur 2 Möglichkeiten: entweder ich nehme das oder ich lass es bleiben.

Ne Münze werfen Ich weiß es auch nicht, nur das ich sowas mal irgendwo gelesen habe (könnte auch im Zusammenhang mit Datenbanken gewesen sein).

Da hast Du ganz offensichtlich Quatsch gelesen, egal in welchem Zusammenhang.

Deadlocks sind "dead". No rescurrection possible.

So is es Alda!


Grüße
Erik

[Jidder]

Und wie soll bestimmt werden welcher der beteiligten der Verlierer ist?

Ne Münze werfen Ich weiß es auch nicht, nur das ich sowas mal irgendwo gelesen habe (könnte auch im Zusammenhang mit Datenbanken gewesen sein).

Ich denke auch, dass das eher im Kontext von Datenbanken war. Da ist sowas möglich, weil da nicht Prozesse sondern Transaktionen die Locks anfordern, also die Einheit, die da dann terminiert wird, ist kleiner. Und natürlich gibt es da verschiedene Strategien, um die unnötig verrichtete Arbeit zu minimieren.

Transaktionen kann man aber sicherlich auch im Kernel machen. EROS und Nachfolger haben zum Beispiel Checkpoints im Kernel. Ich weiß nicht, ob die dafür gedacht sind, aber es sollte prinzipiell auch möglich sein.

[FlashBurn]

Transaktionen kann man aber sicherlich auch im Kernel machen.

Da kommt mir die Idee (die sehr speicherverschwenderisch ist) das man halt wie bei DBs immer Transaktionen hat und die laufen entweder vollständig ab oder gar nicht.

Wenn man dann immer erstmal in einer Kopie der Daten (deswegen speicherverschwenderisch) arbeitet und erst wenn die Transaktion vollständig war, wird die Kopie die eigentlichen Daten, sollte man Deadlocks und das entziehen von Locks doch auch irgendwie hinbekommen.

Auf ner 64bit Architektur und Copy-On-Write sollte das mit der Kopie der Daten auch gehen.

[erik.vikinger]

Hallo,

Da kommt mir die Idee ....

Ich glaube nicht das sowas im Rahmen eines OS-Kernel umsetzbar ist. Selbst wenn Du an Kopien arbeitest musst Du diese Änderungen ja irgendwann wieder in die echten Strukturen integrieren und das muss atomar sein. Klar kann man da eine Menge an "Robustheit" durch einen passenden Aufbau der Strukturen erreichen aber um die Notwendigkeit der Atomizität wirst Du an vielen Stellen trotzdem nicht rum kommen.


Grüße
Erik

[FlashBurn]

aber um die Notwendigkeit der Atomizität wirst Du an vielen Stellen trotzdem nicht rum kommen.

Dann hast du die Idee nicht richtig verstanden. Du schützt, wie bisher auch, deine Datenstrukturen durch einen Lock, bekommst du den, arbeitest du auf ner Kopie der Daten und erst wenn du den Lock wieder freigeben willst, werden die Daten auf denen du gearbeitet hast (die Kopie) zu den dann verwendeten Daten und der Lock wird erst danach freigegeben. Die Atomizität ist damit gegeben. Es ging ja nur darum, das du dann in der Lage bist, jemanden nen Lock zu entziehen ohne das es Probleme gibt.

Du könntest sogar soweit gehen, das du ne ReadWrite-Lock so implementierst, das du das Write erstmal immer Copy-On-Write machst und erst wenn du fertig bist mit deiner Arbeit und den Lock wieder freigibst, werden die originalen Daten auch für die Reader gelockt und die Daten werden kopiert (was auf das austauschen einer bzw. mehrerer Pages hinaus läuft) und dann können wieder die Reader lesen.

Sowas würde ich aber erst unter 64bit umsetzen wollen, weil da unter Umständen doch ganz schön virtueller Speicher verbraten wird.

Einziger Nachteil, der mir so spontan einfällt, ist dass du entweder alle Daten (die zusammengehören) in einen "Bereich" (virtueller Adressbereich) packen musst, oder den ganzen Kernel in dem Moment für den einen Thread Copy-On-Write machst (wie man das machen kann, ist mir gerade auch nicht ganz klar, obwohl es kein Problem sein sollte, da immer nur ein Writer vorhanden sein darf).

Ich denke die Idee kommt auf meine Liste für nen 64bit OS (was irgendwann in 10Jahren oder so mal in Angriff genommen wird ).

[Svenska]

Die Idee ist Blödsinn.

Dir geht es darum, Locks ohne Schaden entziehen zu dürfen. Das ist Unfug, denn es läuft dem Existenzgrund von Locks zuwider. Du darfst dir aber gerne sogenannte lock-free data-structures anschauen, sowas gibt es inzwischen auch.

Deadlocks geschehen entweder reproduzierbar aus Logikfehlern, also z.B. falsche Locking-Reihenfolge, oder schlecht reproduzierbar durch Race Conditions, also ungenügend/schlecht geschützte Strukturen, die hätten geschützt sein müssen.

Ersteres kann nur durch Nachdenken behoben werden, gegen letzteres hilft dein Ansatz aber auch nicht, versteckt aber das Problem: entweder läuft dein Code beim Vertauschen in den Deadlock, oder einer der beiden zugreifenden Prozesse verliert seine Änderungen.

Du willst also Probleme verstecken, die du nicht gefixt kriegst. Das ist Symptombehebung und damit Blödsinn.

[FlashBurn]

Dir geht es darum, Locks ohne Schaden entziehen zu dürfen.

Auch, aber die ReadWrite-Sache könnte unter Umständen der Performance helfen.

Du darfst dir aber gerne sogenannte lock-free data-structures anschauen, sowas gibt es inzwischen auch.

Ich weiß, die eine Sache dazu die ich mir angesehen habe, war aber (meiner Meinung nach) Unfug bzw. auch nur nen Lock nur halt anders implementiert.

Deadlocks geschehen entweder reproduzierbar aus Logikfehlern

Naja, einige Deadlocks die ich schon hatte, waren leider nicht so wirklich reproduzierbar, weil nämlich die Zeit (gerade auf SMP Systemen) auch nen Faktor spielt und das kann man immer so schlecht reproduzieren.

Ersteres kann nur durch Nachdenken behoben werden

Das ist mir auch durch den Kopf gegangen, dass Deadlocks ja eigentlich ganz "einfach" zu lösen sind. Das beste gegen Deadlocks ist keine Locks zu benötigen, ansonsten sollte man versuchen das man immer nur einen Lock zur gleichen Zeit haben darf, dann können (eigentlich) auch keine Deadlocks auftreten.

Das ist Symptombehebung und damit Blödsinn.

Dem muss ich mal wiedersprechen. Ich bin mir jetzt nicht sicher ob man das als Symptom bezeichnen kann, aber z.B. CPU-Bugs die fixed du ja auch nicht (wie auch ), sondern du versuchst das Problem zu umgehen (weiß nicht wie ich es anders sagen soll) und das ist auch kein Blödsinn, sondern einfach nötig.

[erik.vikinger]

Hallo,

ansonsten sollte man versuchen das man immer nur einen Lock zur gleichen Zeit haben darf, dann können (eigentlich) auch keine Deadlocks auftreten.

Das ist eine sehr gute Idee. Wenn Du doch mehrere Locks benötigst dann musst Du 100%-tig darauf achten dass das wirklich immer in der selben Reihenfolge passiert (es wäre eigentlich schön wenn es für sowas ein Tool gäbe). Das Problem wenn man zu wenige Locks hat ist das dann ganz schnell die Situation mit dem Big-Kernel-Lock bei raus kommt, die ist zwar sehr einfach zu implementieren und auch sehr sicher gegen Fehler usw. aber eben auch extrem langsam. Wenn man es besser machen will dann muss man das ganze eben passend strukturieren und planen.

aber z.B. CPU-Bugs die fixed du ja auch nicht (wie auch ), sondern du versuchst das Problem zu umgehen (weiß nicht wie ich es anders sagen soll) und das ist auch kein Blödsinn, sondern einfach nötig.

CPUs sind was ganz was anderes, wenn Du die schon gekauft hast und dann erst nen Bug findest dann bleibt Dir auch nichts anderes übrig als Dich damit zu arrangieren oder vielleicht noch auf die Kulanz des Herstellers hoffen. Aber wenn Du in einem Stück Software einen Fehler findest dann kannst Du den beheben und neu compilieren und gut is. Du versuchst da Äpfel mit Birnen zu vergleichen.


Grüße
Erik