Lowlevel
Lowlevel => Lowlevel-Coding => Thema gestartet von: FlashBurn am 17. October 2010, 20:16
-
Ich mache diesmal ein seht weitreichendes Thema auf, da ich genau deswegen gerade Probleme habe, meinen Kernel wieder (vorher ist das Problem einfach nur noch nicht aufgetreten) zum Laufen zu bekommen.
Im speziellen geht es darum, wie man einen sogenannten TLB-Shutdown macht. Also der TLB auf allen CPUs synchronisiert werden muss.
Ich habe das bei mir so gelöst, das man Nachrichten an andere CPUs verschicken kann (per IPI) und man selbst dann wartet bis alle anderen CPUs die Nachricht abgearbeitet haben.
Mein Problem ist nun, das eine CPU die Ints aus hat, weil sie sich in einem kritischen Bereich befindet und versucht einen Lock zu bekommen. Diesen Lock hat nun aber die CPU die gerade eine Nachricht an alle anderen CPUs schickt. Der Deadlock entsteht dadurch das die eine CPU darauf wartet einen Lock zu bekommen und die Ints aus sind und die andere wartet darauf das die gesendete Nachricht bearbeitet wird und auch bei ihr sind die Ints aus.
Wenn ihr jetzt meint "dann mach doch einfach die Ints an", das ist leider nicht so einfach. Dieses spezielle Lock schützt die PagingTables eines Prozesses vor dem gleichzeitigen Zugriff (und außerdem ist es einfacher wenn ich davon ausgehen kann dass das Ändern alles auf ein und der selben CPU passiert) und ich muss auch von genau dieser CPU aus die IPI versenden.
Eine andere (vermeintliche) Lösung wäre einfach das Lock freizugeben, die Ints auszulassen und die andere CPU bekommt den Lock.
Dann habe ich trotzdem nen Deadlock, weil dann beide (immernoch) die Ints aus haben und beide jetzt versuchen ne Msg zu senden.
Einzige Lösung, die mir eingefallen ist, wäre das diese spezielle Funktion nur mit angeschalteten Ints aufgerufen werden darf, aber das ist leider nicht wirklich möglich.
Hat wer schon seinen Kernel so weit und SMP Unterstützung und hat das Problem gelöst?
@erik
Wie willst du solch ein Problem lösen? Denn dein Kernel ist ja grundsätzlich nicht unterbrechbar.
-
Hallo FlashBurn,
ich kann nicht wirklich Dein Problem erkennen.
Ich versuche das mal mit eigenen Worten zu wiederholen:
Du hast 2 CPUs (klar es sind noch mehr CPUs im System), CPU A hat einen Lock (zum modifizieren eines Pgaing-Directorys) und möchte nun an alle anderen CPUs einen IPI schicken damit diese ihren TLB löschen (um die Änderungen zu übernehmen), CPU B möchte gerade den selben Lock bekommen (hat ihn aber noch nicht) und hat deswegen ihre INTs abgeschaltet.
Hab ich Dich richtig verstanden?
Wenn ja dann ist die Lösung so einfach wie offensichtlich, wenn man einen Lock in einem unterbrechbaren Kernel haben will dann müssen für den Versuch diesen zu bekommen zwar die INTs aus sein aber falls dieser Versuch nicht klappt müssen die INTs kurz angeschaltet werden.lock_holen:
cli //IRQs abschalten
mov al,1 //den Wert für belegt in AL laden
xchg [ebx],al //Versuchen den Lock zu holen (das LOCK-Präfix ist für xchg nicht nötig), ebx ist passend vorbelegt
cmp al,0 //war Lock vorher frei?
je lock_bekommen //wenn ja dann habe ich den jetzt
sti //IRQs wieder anschalten
pause //oder irgendwas anderes damit die CPU mal kurz inne hält
jmp lock_holen //auf ein neues
lock_bekommen:ich hoffe Du verstehst was ich meine. Bei dem sti müsste noch eine Abfrage hin ob die INTs auch vorher an waren damit nichts böses passiert.
Wenn ich Dein Problem falsch verstanden habe dann erkläre es bitte noch mal etwas deutlicher (und benutze A und B für die CPUs damit man nicht durcheinander kommt).
Auf meiner Plattform trifft dieses TLB-Problem grundsätzlich nicht auf, bei mir soll es möglich sein das eine CPU über ein spezielles Controll-Register (sowas wie die MSR bei x86) einen globalen TLB-Flush für eine bestimmte Page auslösen kann. Die CPUs führen das in HW aus ohne die gerade laufende SW zu unterbrechen, einzig die Suche im TLB nach der zu löschenden Page hindert die laufende SW kurz daran einen gepageten Speicherzugriff durchzuführen (die CPU-Pipeline würde blockieren), wenn die Segmente der laufenden SW ohne Paging auskommen (was wohl die Regel ist) dann merkt die SW gar nichts davon. Die CPU welche das initiiert hat blockiert natürlich bis alle anderen ein Okay zurückmelden, was durchaus einige 100 bis 1000 Takte dauern kann, aber etliche IPIs loszutreten dauert sicher länger (vor allem trotz dessen das die meisten CPUs die betreffende Page gar nicht im TLB haben). Im Gegenzug gibt es auf meiner Plattform keine IPIs und damit auch keine Möglichkeit eine bestimmte CPU zu einer Reaktion zu bewegen. Trotzdem denke ich das mein System gerade wegen solcher Kleinigkeiten deutlich besser skalieren wird.
Grüße
Erik
-
Wenn ich Dein Problem falsch verstanden habe dann erkläre es bitte noch mal etwas deutlicher (und benutze A und B für die CPUs damit man nicht durcheinander kommt).
Ich würde nicht sagen das du es falsch verstanden hast, sondern nicht komplett.
Dein Vorschlag hatte ich schon vor Ewigkeiten (wegen solcher Probleme) umgesetzt.
Man hat ne vmmMap()-Funktion und um sich die Arbeit zu erleichtern darf immer nur einer gleichzeitig in den PageTables eines Prozesses (und der KernelSpace ist für ich in dem Fall ein extra Prozess) rumwerkeln. Also sichere ich den Code durch einen Lock und wenn man das Lock hat dann sind die Ints aus. Soweit kein Problem. Mein Problem ist nun das ich eigentlich sagen muss, dass diese vmmMap() nur mit eingeschalteten Ints aufgerufen werden darf, aber genau das bekomme ich ohne viele neue Probleme an anderen Stellen nicht hin.
Dadurch kann es jetzt halt passieren, das jemand auf CPU A im KernelSpace was gemappt hat und nen TLB-Shutdown macht, aber auf CPU B ist jemand in einem kritischen Bereich und hat seine Ints aus und ruft jetzt dummerweise vmmMap() auf und will eine Page im KernelSpace mappen. Den Lock kann er natürlich nicht bekommen, weil CPU A den hat und ihn erst freigibt, wenn der TLB-Shutdown abgeschlossen. Dies wiederrum kann nicht geschehen, weil CPU B die Ints nicht an hat und so nie die IPI-Nachricht bearbeitet.
Um es einfacher zu machen, was wird wohl einfacher sein, mir alle Funktionen angucken die die Ints aus haben und vmmMap() angucken oder versuchen vmmMap() und den TLB-Shutdown anders zu gestalten?
Meine Vermutung ist, das ich mir alle Funktionen angucken muss die die vmmMap mit ausgeschalteten Ints aufrufen und zusehen muss das ich das nicht mehr mache.
Ich werde nachher mal eins der Probleme posten, die anderen sehen ähnlich aus.
-
Hallo,
wenn Dein Problem so ist dann empfehle ich Dir das man bei verschachtelten Locks immer in der selben Reihenfolge locken muss. Klingt vielleicht doof und lässt sich wohl nicht so ganz mit Deiner Zielvorstellung in Einklang bringen aber schlussendlich wirst du da kaum drumherum kommen.
Wenn die CPU A mit ihren Modifikationen am Page-Directory fertig ist und anschließend alle anderen CPUs nur noch darüber informieren möchte, ist da der Lock wirklich noch erforderlich? Wäre es nicht möglich den Lock freizugeben nachdem alle Änderungen erledigt sind aber bevor die anderen CPUs informiert werden? Ich weiß ja nicht genau wie Deine Speicherverwaltung arbeitet aber ich sehe da eigentlich kein Erfordernis den Lock zu behalten.
Grüße
Erik
-
wenn Dein Problem so ist dann empfehle ich Dir das man bei verschachtelten Locks immer in der selben Reihenfolge locken muss. Klingt vielleicht doof und lässt sich wohl nicht so ganz mit Deiner Zielvorstellung in Einklang bringen aber schlussendlich wirst du da kaum drumherum kommen.
Das ist klar und wird auch so gemacht, aber (um bei meinem Bsp. zu bleiben) die vmmMap() wird ja nicht nur von einer anderen Funktion aus aufgerufen und d.h. dann auch das da noch andere Locks mit im Spiel sind.
Wenn die CPU A mit ihren Modifikationen am Page-Directory fertig ist und anschließend alle anderen CPUs nur noch darüber informieren möchte, ist da der Lock wirklich noch erforderlich? Wäre es nicht möglich den Lock freizugeben nachdem alle Änderungen erledigt sind aber bevor die anderen CPUs informiert werden? Ich weiß ja nicht genau wie Deine Speicherverwaltung arbeitet aber ich sehe da eigentlich kein Erfordernis den Lock zu behalten.
Praktisch ist der Lock erforderlich.
Stell dir einfach vor du möchtest mehr als eine Page mit einem Aufruf von vmmMap() mappen und jetzt stell dir mal vor die Funktion wird nach jeder Page unterbrochen und läuft dann jedesmal auf ner anderen CPU. Unschön, aber noch zu handeln. Denn jetzt könntest du sagen, ok machen wir einfach so, beim TLB-Shutdown wird einfach jede CPU (auch die die die IPI versendet) angeschrieben und invalidet den TLB. Die Variante ist aus Performance sicht natürlich absolute scheiße (zumal ich bei meiner Variante noch ein wenig optimieren kann).
Das Problem ist, halt, dass das Versenden der IPI Nachricht auf der selben CPU (A) stattfinden muss, weil es sonst passiert das dieser Teil auf ner anderen CPU B stattfindet und die ihren TLB also nicht aktualisiert, aber die andere CPU A invalidet ihren TLB nochmal.
Lange Rede kurzer Sinn, ich behalte den Lock, damit ich davon ausgehen kann dass das Senden der IPI Nachricht auf der selben CPU stattfindet wie das mappen. Den Lock zu behalten hat den Sinn, die Ints auszulassen.
-
Hallo,
ich würde sagen Du sollst nicht jede Page einzeln mappen und immer sofort alle TLBs invalidieren sondern erst alle Pages mappen und erst am Schluss alle TLBs invalidieren. Zu häufiges TLB invalidieren kosten nur unnötig Performance (das solltest Du nicht unterschätzen). Das einzigste was Du sicherstellen musst ist das bevor die Pages das erste mal benutzt werden es keine Altlasten in den TLBs gibt. Von welcher CPU das Invalidieren der TLBs dann ausgeht ist doch völlig egal solange Du keine CPU vergisst.
Grüße
Erik
-
ich würde sagen Du sollst nicht jede Page einzeln mappen und immer sofort alle TLBs invalidieren sondern erst alle Pages mappen und erst am Schluss alle TLBs invalidieren. Zu häufiges TLB invalidieren kosten nur unnötig Performance (das solltest Du nicht unterschätzen). Das einzigste was Du sicherstellen musst ist das bevor die Pages das erste mal benutzt werden es keine Altlasten in den TLBs gibt. Von welcher CPU das Invalidieren der TLBs dann ausgeht ist doch völlig egal solange Du keine CPU vergisst.
So schlimm ist es bei mir auch nicht.
Also:
vmmMap(void *virt, void *phys, uint32t count, struct addrSpace_t *addrSpace) {
spinAcquire(&addrSpace->lock);
for(uint32t x= 0; x < count; x++, virt+= PG_SIZE, phys+= PG_SIZE) {
//hier packt er jetzt die phys in die PageTables
invalidTLB(virt);
}
smpSendBroadcastMsg(SMP_CODE_INVALIDPG,virt,count,getPD());
spinRelease(&addrSpace->lock);
}
Das wäre mal ne sehr stark vereinfachte Variante der vmmMap().
Dein Vorschlag heißt also das ich das invalidieren nicht in der Schleife mache, sondern das ich ne Nachricht sende und die geht an alle einschließlich der CPU die die Nachricht gesendet hat.
Wäre ne Möglichkeit. Schwierigkeit sehe ich halt dann darin, das ich auch das Senden der Nachricht in einen Lock packe und da ja wieder keine Ints an sind und somit die sendende CPU wieder die Nachricht nicht bekommen würde.
Ich muss das Senden mit nem Lock schützen, da ich immer nur eine Nachricht zur selben Zeit senden und bearbeiten lassen kann.
Edit::
Was mir noch einfällt. Deine Lösung das ich den Lock freigeben und erst später an alle CPUs die Nachricht sende, kann auch deswegen nicht funktionieren, weil es wieder einen Deadlock (obwohl ich inzwischen glaube, dass das das falsche Wort dafür ist) gibt.
Denn Problem an deinem Vorschlag und meinem momentanen Code ist, dass beide davon ausgehen (müssen) das die Ints vorher an waren und genau das ist das Problem.
Edit::
Auf meiner Plattform trifft dieses TLB-Problem grundsätzlich nicht auf, bei mir soll es möglich sein das eine CPU über ein spezielles Controll-Register (sowas wie die MSR bei x86) einen globalen TLB-Flush für eine bestimmte Page auslösen kann.
Wenn ich dich hier richtig verstehe dann willst du nen TLB-Flush mit der physikalischen und nicht der virtuellen Adresse machen?
Das würde so bei mir gar nicht funktionieren, weil es durchaus sein kann, das ein und die selbe physikalische Page an mehreren virtuellen Adressen gemappt ist.
-
Hallo,
aber (...) die vmmMap() wird ja nicht nur von einer anderen Funktion aus aufgerufen und d.h. dann auch das da noch andere Locks mit im Spiel sind.
Das korrekte Locken muss man immer über die gesamte SW und alle Ausführungspfade betrachten.
Dein Vorschlag heißt also das ich das invalidieren nicht in der Schleife mache, sondern das ich ne Nachricht sende und die geht an alle einschließlich der CPU die die Nachricht gesendet hat.
Ja, Du sollst erst das PD fertig bearbeiten und danach alle TLBs löschen. Somit kannst Du zum TLB-Löschen den Lock, fürs PD, freigeben.
Schwierigkeit sehe ich halt dann darin, das ich auch das Senden der Nachricht in einen Lock packe und da ja wieder keine Ints an sind und somit die sendende CPU wieder die Nachricht nicht bekommen würde.
In der eigentlichen IPI-Sende-Funktion, welche für jede Ziel-CPU einzeln aufgerufen wird und internen einen Lock benutzt, muss natürlich die aktuelle CPU als Ziel ausgefiltert werden (die gewünschte Aktion muss dann direkt ausgeführt werden).
Denn Problem an deinem Vorschlag und meinem momentanen Code ist, dass beide davon ausgehen (müssen) das die Ints vorher an waren und genau das ist das Problem.
Also ich sehe nicht wo mein Vorschlag bedingt das die INTs vorher an sind.
Wenn ich dich hier richtig verstehe dann willst du nen TLB-Flush mit der physikalischen und nicht der virtuellen Adresse machen?
Da hast Du mich missverstanden, ich will das TLB-Löschen auch mit linearen Adressen machen. Ich hab zwar nur ein einziges Page-Directory im gesamten System aber auch dort können physische Pages an mehreren Stellen im linearen Adressraum gemappt sein.
Grüße
Erik
-
In der eigentlichen IPI-Sende-Funktion, welche für jede Ziel-CPU einzeln aufgerufen wird und internen einen Lock benutzt, muss natürlich die aktuelle CPU als Ziel ausgefiltert werden (die gewünschte Aktion muss dann direkt ausgeführt werden).
Sorry, wenn ich das mal so sage, aber das ist sehr unvorteilhaft ;)
Wie lange soll das dauern, wenn du die Sende-Funktion für jede CPU einzeln aufrufst (max. 255 mal)? Dann kommt noch hinzu das der Vorteil, der gleichzeitigen Bearbeitung auch flöten geht.
Viel einfacher ist es, wenn ich eine Nachricht schicke und die geht entweder an alle oder an alle außer der sendenden.
Das die aktuelle CPU den Code direkt ausführen soll, ist auch eher unvorteilhaft (zwecks extra Behandlung).
Also ich sehe nicht wo mein Vorschlag bedingt das die INTs vorher an sind.
Das Senden ist durch einen Lock geschützt und als sendende CPU (A) wartest du (und behälst damit den Lock) bis alle CPUs die Nachricht bearbeitet haben und genau das ist der springende Punkt. Jemand kommt mit Ints aus bei der IPI-Sende-Funktion an und möchte den Lock (CPU B).
Den wird er nur nie bekommen, denn es hat gerade eine CPU (A) den Lock und die wartet auf genau die CPU (B) die gerade versucht den Lock zu bekommen und mit Ints aus da rein ist. Da sie (CPU B) schon die Ints aus hatte als sie rein kam, wird sie die Nachricht nicht (bzw. sogar nie) bekommen.
Eine andere Idee die ich noch hatte, ist es das man mehrere Msgs senden kann. Das sollte dann so aussehen, das die Msgs in einer Queue sind und jede CPU die Msgs der Queue durchgeht und guckt ob sie sie bearbeiten muss. Hat die CPU die Msg bearbeitet setzt es das Bit in einer Bitmap und erhöht nen Counter, ist der Counter gleich der Anzahl der CPUs wird die Nachricht "gelöscht".
So kann ich einfach mehrere Msgs senden und muss auch nicht mehr darauf warten das eine Nachricht bearbeitet wurde.
Alles gut und schön, aber da habe ich dann immernoch eine "Bedingung", nämlich das wenn man vmmMap() aufgerufen hat, man die Page(s) die man gemappt hat erst benutzen darf, wenn man die Ints an hatte. Denn ansonsten nutzt du die Page und hast den TLB noch gar nicht aktualisiert (was ich natürlich mache in meinen Problemfunktionen :( ).
Allerdings sollte das Problem des nicht aktualisierten TLBs eigentlich gar keins sein. Denn was kann schon passieren? Wurde die Page neu gemappt, ist (eigentlich) eh kein Eintrag vorhanden und es muss in die PageTables geschaut werden.
Blöd wird es erst wenn da vorher ne andere Page stand und ein vmmUnmap() mit einem vmmMap() (auf einer anderen CPU) mit der selben virtuellen Adresse kollidiert (was eigentlich nicht passieren darf).
Jetzt weißt du hoffentlich warum man einen unterbrechbaren Kernel haben sollte!?
-
Hallo,
Sorry, wenn ich das mal so sage, aber das ist sehr unvorteilhaft
Tja, ich hab eben keine Ahnung davon wie die IPIs auf x86 realisiert sind, ich weiß nur das ich auf meiner Plattform keine IPIs brauche (wozu auch?) und demzufolge auch keine habe.
Viel einfacher ist es, wenn ich eine Nachricht schicke und die geht entweder an alle oder an alle außer der sendenden.
Dann eben "an alle außer der sendenden". Wo ist das Problem?
Das die aktuelle CPU den Code direkt ausführen soll, ist auch eher unvorteilhaft (zwecks extra Behandlung).
Warum, einen TLB-Flush wirst Du doch überall mal kurz ausführen können.
Das Senden ist durch einen Lock geschützt .....
Das klingt irgendwie kompliziert. Kann man an diese Sache nicht anders ran gehen?
.... und muss auch nicht mehr darauf warten das eine Nachricht bearbeitet wurde.
Nach einem vmmUnmap() solltest Du aber schon warten bis wirklich alle CPUs ihren TLB gelöscht haben.
Allerdings sollte das Problem des nicht aktualisierten TLBs eigentlich gar keins sein. Denn was kann schon passieren? Wurde die Page neu gemappt, ist (eigentlich) eh kein Eintrag vorhanden und es muss in die PageTables geschaut werden.
Ich weiß zwar nicht wie Intel und AMD das implementieren aber es wäre schon ziemlicher Unsinn wenn ungültige PD-Einträge in den TLB kommen könnten. Ich denke Deine Annahme ist richtig.
Blöd wird es erst wenn da vorher ne andere Page stand und ein vmmUnmap() mit einem vmmMap() (auf einer anderen CPU) mit der selben virtuellen Adresse kollidiert (was eigentlich nicht passieren darf).
Nach einem vmmUnmapp() muss man tatsächlich warten bis alle CPUs ihren TLB aktualisiert haben aber dort gibt es ja auch keine neuen Pages die man gleich benutzen will und es sollte auch kein Problem sein nach einem vmmUnmap() mal die INTs an zuschalten.
Jetzt weißt du hoffentlich warum man einen unterbrechbaren Kernel haben sollte!?
Ich weiß jetzt nur noch deutlicher warum ich keinen unterbrechbaren Kernel will! Das ist ja ein unheimlicher Zusatzaufwand der da getrieben werden muss! Vor allem kann ich für einen Micro-Kernel keinen Vorteil dadurch erkennen.
Grüße
Erik
-
Ich weiß jetzt nur noch deutlicher warum ich keinen unterbrechbaren Kernel will! Das ist ja ein unheimlicher Zusatzaufwand der da getrieben werden muss! Vor allem kann ich für einen Micro-Kernel keinen Vorteil dadurch erkennen.
Du kommst einfach auf x86 um einen unterbrechbaren Kernel nicht herum!
Warum, einen TLB-Flush wirst Du doch überall mal kurz ausführen können.
Mir geht es in dem Fall eigentlich darum, das ich keinen doppelten Code habe, weil ich müsste die Nachrichten Behandlung ja einmal im Handler haben und einmal im Sende-Code was natürlich quatsch ist.
Das klingt irgendwie kompliziert. Kann man an diese Sache nicht anders ran gehen?
Bin ich gerade dabei ;) Wenn ich fertig bin und es funktioniert so wie ich es mir vorstelle, dann muss man nur noch einen Lock haben, damit man eine neue Nachricht in die Liste packen kann. Man muss dann auch nicht mehr warten bis alle anderen CPUs die Nachricht bearbeitet haben.
Allerdings muss der Sendevorgang an sich (das Schreiben, genauer 2 32bit Werte, in ein 64bit APIC Register) durch deaktivierte Ints geschützt werden.
Nach einem vmmUnmap() solltest Du aber schon warten bis wirklich alle CPUs ihren TLB gelöscht haben.
Nö ;)
Ich gehe immernoch davon aus, das auf der aktuellen CPU die TLBs in Ordnung sind und wenn ich die Nachricht gesendet habe, kann mir alles andere egal sein.
Was ich machen könnte, ist am Ende von vmmMap() und vmmUnmap() nachzusehen ob nicht irgendwelche IPI Nachrichten da sind und diese dann bearbeiten oder noch besser bevor ich eine neue Nachricht sende, wird nachgeguckt ob ich nicht erstmal alte bearbeiten sollte.
Ich denke ich werde letzteres umsetzen.
Nach einem vmmUnmapp() muss man tatsächlich warten bis alle CPUs ihren TLB aktualisiert haben aber dort gibt es ja auch keine neuen Pages die man gleich benutzen will und es sollte auch kein Problem sein nach einem vmmUnmap() mal die INTs an zuschalten.
Nein und nein ;)
Also das Problem was ich meine ist, das CPU A nen Unmap macht (und die Ints aus sind) und auf CPU B macht jemand danach nen Map (mit Ints aus und der gleichen virtuellen Adresse).
Jetzt steht in den PageTables schon ein korrekter neuer Wert drin, aber da nicht alle CPUs aktuelle TLBs hat, kann es passieren das einer auf ne alte Page zugreift.
Die Ints kann ich deswegen nicht mal eben wieder anmachen, weil es bei mir Code gibt, der auf der selben CPU beendet werden muss, auf der er auch begonnen wurde und dann kann man nicht mal eben die Ints anmachen.
-
Ich gehe immernoch davon aus, das auf der aktuellen CPU die TLBs in Ordnung sind und wenn ich die Nachricht gesendet habe, kann mir alles andere egal sein.
Ich kann sagen, dass das so nicht stimmt ;)
Mein Kernel läuft wieder auf mehreren CPUs, mehr oder weniger :(
Also wer sein OS möglichst erstmal "nur" zum Laufen bringen will, sollte von SMP (d.h. nicht das man kein Multithreading machen soll) erstmal Abstand halten!
Es ist einfach eine Qual Code zu debuggen der auf mehreren CPUs gleichzeitig läuft. Ich bin mir nicht sicher ob ich noch irgendwo ein Locking Problem habe (obwohl da wo es zu sein scheint, kann es eigentlich nicht sein) oder ob ich ein Problem mit fehlerhaften bzw. nicht aktuellen TLBs habe.
Die Symptome sind, dass mein Kernel die meiste Zeit, wenn ich ihn in Bochs oder Qemu teste, läuft, aber ab und zu kommt entweder ein Locking Problem oder ein Fehler der nach fehlerhaften bzw. nicht aktuellen TLB aussieht.
Edit::
Ich denke ich kann inzwischen die Probleme mit dem TLB-Shutdown und nicht aktuellen TLBs einschränken.
Mit meiner neuen Variante IPI-Nachrichten zu versenden und zu bearbeiten offenbart sich leider immer mehr ein Problem mit dem Locking.
Um es mal an einem Bsp. zu zeigen. Ich habe ja ne relativ aktuelle Variante des SlabAllocators implementiert und bei dieser ist es so das man sogenannte Magazine (kleine Stacks, die bei mir 4 Objekte beinhalten) pro CPU benutzt. Hat den Vorteil das, solange mind. 1 Objekt in dem Magazin ist, dass allokieren verdammt schnell geht.
Leider hat es den Nachteil, das man während man guckt ob noch Objekte im Magazine sind die Ints ausmachen muss, da das ja alles auf der selben CPU laufen muss. So weit ist da auch noch kein Problem.
Problematisch wird es wenn das Magazin aufgefüllt werden muss. Dazu wird der "alte", "einfache" SlabAllocator aufgerufen. Auch das muss wieder auf der gleichen CPU passieren, weil ansonsten könnte es passieren das man versucht das Magazin einer anderen CPU aufzufüllen, das gar nicht leer ist bzw. sogar voll ist.
Das ist auch immernoch kein Problem. Erst wenn der VMM aufgerufen wird, weil der SlabAllocator ne neue Page braucht tritt ein Problem auf. Solange das alles auf der CPU passiert die ihr Magazin neu befüllen muss funktioniert das auch. Wenn jetzt aber eine andere CPU auch ihr Magazin auffüllen will und dann auf die neue Page zugreift kann das schief gehen.
Denn die Ints sind ja aus, da alles auf der gleichen CPU laufen muss, und damit wird auch nicht der TLB aktualisiert und es wird ein alter Eintrag genutzt.
Ich hoffe ihr konntet das Problem nachvollziehen.
Ich suche jetzt nach einer vernünftigen Lösung dafür, aber bisher ist mir nichts eingefallen. Die einzige Idee die mir kam, war den IPI-Service-Int weg von einem normalen Int hin zu einem NMI zu machen. Damit wird jede CPU immer unterbrochen auch wenn sie eigentlich die Ints aus hat und da ich nur Code ausführe der TLBs aktualisiert sollte das auch kein Problem darstellen.
Was meint ihr?
-
Hallo,
Du kommst einfach auf x86 um einen unterbrechbaren Kernel nicht herum!
Das glaube ich nicht! Das einzigste was ein Problem bei SMP ist ist das löschen der anderen TLBs aber dafür möchtest Du ja NMI benutzen (was IMHO wohl der richtige Weg ist). Für alles andere benötigt man keinen unterbrechbaren Kernel, zumindest solange man bei einem Micro-Kernel bleibt der nur die elementaren Basics wie Speicher, CPU-Zeit und IPC anbietet.
Warum, einen TLB-Flush wirst Du doch überall mal kurz ausführen können.
Mir geht es in dem Fall eigentlich darum, das ich keinen doppelten Code habe
Das TLB löschen ist ein kleines Assembler-Macro:#define TLB_FLUSH asm("mov eax,cr3; \n mov cr3,eax;" : : "eax","memory");und ein TLB_FLUSH an 2 Stellen zu tippen ist jetzt nicht so der Aufwand außerdem macht es Deinen Kernel portabel wenn dieses define in einer plattformspezifischen H-Datei drin ist.
Ich gehe immernoch davon aus, das auf der aktuellen CPU die TLBs in Ordnung sind
Das diese Annahme falsch ist weißt Du ja nun selber. Zumindest bei einem vmmUnmap() musst Du die vorher gültigen PT-Einträge aus dem TLB entfernen. Andersrum ist das nicht so kritisch.
Du darfst aber die Pages, die vmmUnmap() frei gibt, erst dann wieder in den Pool mit den freien Pages legen wenn das TLB-löschen auf allen CPUs fertig ist! Damit diese Pages nicht während dessen schon wieder für etwas neues benutzt werden, dann ist es auch egal auf welcher CPU das alles passiert.
Also wer sein OS möglichst erstmal "nur" zum Laufen bringen will, sollte von SMP (d.h. nicht das man kein Multithreading machen soll) erstmal Abstand halten!
Diesen Rat werde ich bei meiner Plattform nicht befolgen, bei mir ist SMP ein essentieller Bestandteil.
Aber ich hab ja auch nicht so erquickende Dinge wie IPIs. ;)
Es ist einfach eine Qual Code zu debuggen der auf mehreren CPUs gleichzeitig läuft. Ich bin mir nicht sicher ob ich noch irgendwo ein Locking Problem habe (obwohl da wo es zu sein scheint, kann es eigentlich nicht sein) oder ob ich ein Problem mit fehlerhaften bzw. nicht aktuellen TLBs habe.
Du bist es offensichtlich nicht gewöhnt in parallelen Bahnen zu denken, ich kann Dir da nur empfehlen erst mal mit Multithreading-User-Space-Programmen zu üben. Als ich das erste mal für ein Multi-CPU-PC programmiert habe (damals ein 4 x Pentium-Pro) war das für mich auch eine Art Kulturschock, man wird mit so vielen neuartigen Problemen konfrontiert.
.....
Ich hoffe ihr konntet das Problem nachvollziehen.
Nicht so ganz, Du musst Dir mehr Mühe geben keine Henne-Ei-Probleme in Deinem Design zu haben.
Ich suche jetzt nach einer vernünftigen Lösung dafür, aber bisher ist mir nichts eingefallen. Die einzige Idee die mir kam, war den IPI-Service-Int weg von einem normalen Int hin zu einem NMI zu machen. Damit wird jede CPU immer unterbrochen auch wenn sie eigentlich die Ints aus hat und da ich nur Code ausführe der TLBs aktualisiert sollte das auch kein Problem darstellen.
Was meint ihr?
Ich denke solange der TLB-Flush das einzigste ist was Du per IPI machst kannst Du die ruhig als NMI realisieren. Ist bei meiner Plattform ja in gewisser Weise auch so nur das ich das komplett in HW machen möchte um eben in der SW trotzdem ohne eine Unterbrechung aus zukommen.
Hast Du denn vor die IPIs noch für etwas anderes zu benutzen? Mir fällt da ehrlich gesagt nichts ein.
Grüße
Erik
-
Du kommst einfach auf x86 um einen unterbrechbaren Kernel nicht herum!
Also die BSDs haben in ihrer ersten SMP-Implementierung einfach ein GIANT_LOCK genutzt. Manche alten Treiber nutzen diesen Ansatz immernoch, steht dann im Bootlog. Alternativ pinnst du den Kernel auf eine CPU fest und lässt auf den anderen CPUs nur Userspace laufen. Möglichkeiten gibt es, ob sie gut (oder hinreichend gut) sind, ...
-
Das TLB löschen ist ein kleines Assembler-Macro:
Das ist seit dem 486 nicht mehr so bzw. geht viel performanter nämlich mit "invlpg". Mir deiner Variante würde ich ja jedes Mal den ganzen TLB löschen und das ist nicht Sinn der Sache.
Zumal du damit ab PPro richtig Probleme bekommen kannst, denn deine Variante löscht nicht die Einträge die global markiert sind, die musst du alle explizit mit "invlpg" löschen (wimre).
Das diese Annahme falsch ist weißt Du ja nun selber. Zumindest bei einem vmmUnmap() musst Du die vorher gültigen PT-Einträge aus dem TLB entfernen. Andersrum ist das nicht so kritisch.
Wie gesagt, das Löschen im TLB mache ich immer gleich in der vmmMap() und der vmmUnmap() und dann wird einfach nur noch eine IPI-Nachricht verschickt dass das die anderen CPUs (eventuell) auch machen müssen.
Damit ist der TLB auf der aktuellen CPU immer gültig.
Du bist es offensichtlich nicht gewöhnt in parallelen Bahnen zu denken, ich kann Dir da nur empfehlen erst mal mit Multithreading-User-Space-Programmen zu üben. Als ich das erste mal für ein Multi-CPU-PC programmiert habe (damals ein 4 x Pentium-Pro) war das für mich auch eine Art Kulturschock, man wird mit so vielen neuartigen Problemen konfrontiert.
Ich habe von Anfang an so programmiert und meinen Kernel immer für SMP/Multithreading ausgelegt und so programmiert.
Es ist halt ne Tatsache das ein Bug, der nur sporadisch und nach keinem Muster auftritt eher verdammt schwer bis gar nicht zu finden ist.
Gerade bei SMP kann das heißen das dein Kernel mal läuft und mal gibt es nen Deadlock ohne das du weißt warum.
Die ganze Bug Suchgeschichte hatte aber auch seine Vorteile, bei der Suche habe ich mir teile des Codes in Assembler angesehen und da ist mir erstmal aufgefallen wie fehleranfällig mein Lockcode war :roll: Ein Wunder das da bisher nichts passiert ist.
Nicht so ganz, Du musst Dir mehr Mühe geben keine Henne-Ei-Probleme in Deinem Design zu haben.
Das lässt sich aber eigentlich gerade bei einem OS nie vermeiden, irgendjemand muss halt mal irgendwann initialisieren und da gibt es immer so ein Problem. Bei mir treten die halt auch nach der Initialisierung auf ;)
Nächste Sache ist halt, ich könnte wieder den alten SlabAllocator verwenden, der hat nicht die Probleme, aber der ist nicht mal annähernd so schnell und skaliert auch nicht so schön.
Zumal du damit ja indirekt implizierst das man lieber keine komplizierten Sachen/Konzepte nutzen sollte, damit fällt dann auch Multithreading auf mehreren Cores weg. Denn damit holt man sich nen Haufen Probleme und die Komplexität steigt auch nicht ganz unwesentlich.
Hast Du denn vor die IPIs noch für etwas anderes zu benutzen? Mir fällt da ehrlich gesagt nichts ein.
Ja. Wird für Rendevouz-Funktionen genutzt (z.B. TSCs synchronisieren) und dafür alle außer der sendenden CPUs anzuhalten.
Beide Fälle sollten aber kein Problem darstellen. Jetzt muss ich nur noch rausbekommen wie das mit dem NMI funktioniert und dann habe ich durch meinen ersten Versuch das Problem zu lösen meinen IPI-Code für die sendende CPU sogar wesentlich performanter gemacht.
Alternativ pinnst du den Kernel auf eine CPU fest und lässt auf den anderen CPUs nur Userspace laufen.
Ersteres habe ich bei mir nicht implementiert und finde ich auch nicht nötig und zweiteres ist, aus meiner Sicht unmöglich.
Denn was willst du machen, wenn schon 2 CPUs im KernelSpace laufen und den Kernel sozusagen sperren willst. Wenn du daran denkst das immer nur eine CPU in den Kernel darf, dann ist das wieder ne GIANT_LOCK und sowas sollte man heutzutage nicht mal mehr in Betracht ziehen. Das ist nur unnötige Ressourcen Verschwendung weil man zu faul war sich nen Kopf zu machen ;)
-
Alternativ pinnst du den Kernel auf eine CPU fest und lässt auf den anderen CPUs nur Userspace laufen.
Ersteres habe ich bei mir nicht implementiert und finde ich auch nicht nötig und zweiteres ist, aus meiner Sicht unmöglich.
Denn was willst du machen, wenn schon 2 CPUs im KernelSpace laufen und den Kernel sozusagen sperren willst. Wenn du daran denkst das immer nur eine CPU in den Kernel darf, dann ist das wieder ne GIANT_LOCK und sowas sollte man heutzutage nicht mal mehr in Betracht ziehen. Das ist nur unnötige Ressourcen Verschwendung weil man zu faul war sich nen Kopf zu machen ;)
Das das ungeeignet ist, war mir schon klar. Aber du kannst durchaus hingehen und sagen "CPU0 darf Kernel und Userspace ausführen" und "alle anderen CPUs dürfen den Kernel nicht aufrufen". Bei deinem Mikrokernelsystem ist sicher nicht so schädlich wie bei einem Monolithen.
Der GIANT_LOCK-Ansatz wurde bei den BSDs sofort als SMP-Möglichkeit eingeführt, da kannten andere OSse keine Mehrprozessorsysteme, und seitdem wird der Kernel in immer feinere, einzeln gelockte Abschnitte unterteilt, die ihrerseits unterbrechbar sind. Für Neuschreiben (wie bei dir) ist diese Vorangehensweise sicherlich die denkbar schlechteste Lösung.
Darum ging es aber garnicht - dies sind nur Möglichkeiten, ohne unterbrechbaren Kernel auf x86 auszukommen.
Gruß
-
Bei deinem Mikrokernelsystem ist sicher nicht so schädlich wie bei einem Monolithen.
Ich würde sagen, das nimmt sich nicht so viel. Bei nem Mikrokernel wirst du viele Kernelaufrufe zwecks IPC haben, aber dafür sollte die Zeit im Kernel wirklich nicht lange dauern.
Für Neuschreiben (wie bei dir) ist diese Vorangehensweise sicherlich die denkbar schlechteste Lösung.
Du weißt doch, es gibt immer jemanden der es trotzdem macht ;)
-
Hallo,
Das ist seit dem 486 nicht mehr so bzw. geht viel performanter nämlich mit "invlpg".
Okay, dann machst Du aus TLB-Flush eben eine (etwas komplexere) Funktion die an mehreren Stellen aufgerufen wird.
Wie gesagt, das Löschen im TLB mache ich immer gleich in der vmmMap() und der vmmUnmap() und dann wird einfach nur noch eine IPI-Nachricht verschickt dass das die anderen CPUs (eventuell) auch machen müssen.
Damit ist der TLB auf der aktuellen CPU immer gültig.
Das Problem das Du Pages bereits im Frei-Pool hast die aber eventuell noch in TLBs einiger/anderer CPUs drin sind muss aber gelöst werden indem Du alle TLBs löscht bevor die Pages in den Frei-Pool kommen. Das senden der IPIs und warten auf alle Antworten muss also in der Mitte von vmmUnmap() passieren und nicht erst hinterher.
Ich habe von Anfang an so programmiert und meinen Kernel immer für SMP/Multithreading ausgelegt und so programmiert.
Sicher? Warum hast Du dann jetzt so viele Probleme damit? ;)
"Der Mensch denkt oft richtig aber nur selten vollständig."
Ich bestreite nicht das Du Dir Mühe gibst aber aus Deinen vergangenen Problembeschreibungen habe ich den subjektiven Eindruck gewonnen das Dir da etwas an Erfahrung fehlt und Du deswegen verschiedene Probleme nicht so deutlich/frühzeitig erkennst. Beim Programmieren von Algorithmen, in dehnen viele Dinge parallel und in unvorhersehbarer Reihenfolge ausgeführt werden, gibt es eben eine Reihe von Problem-Klassen für die man erst etwas Übung braucht um damit ganz selbstverständlich umgehen zu können.
Es ist halt ne Tatsache das ein Bug, der nur sporadisch und nach keinem Muster auftritt eher verdammt schwer bis gar nicht zu finden ist.
Das hat aber nichts mit SMP zu tun. Du solltest mal ganz klar definieren was ein Bug ist und dann Code schreiben der zur Laufzeit (in der Debug-Version) nach genau dieser Bedingung prüft. Mit diesem Weg kommst Du zu recht präzisen Debug-Meldungen, zumindest bin ich bis her damit recht gut gefahren.
Gerade bei SMP kann das heißen das dein Kernel mal läuft und mal gibt es nen Deadlock ohne das du weißt warum.
Jedes mal wenn Du einen Deadlock hast musst Du die Ursache heraus finden und dann wird Dein Code mit jedem beobachteten Deadlock besser.
Das lässt sich aber eigentlich gerade bei einem OS nie vermeiden
Was ist an einem OS so anders als an anderen Programmen das bei OSen eben Henne-Ei-Probleme nicht vermieden werden können? Klar gibt es ein paar zusätzliche Schwierigkeiten aber die sind IMHO nicht unlösbar.
Bei mir treten die halt auch nach der Initialisierung auf
Also doch Design-Probleme?! ;)
Zumal du damit ja indirekt implizierst das man lieber keine komplizierten Sachen/Konzepte nutzen sollte
Das meine ich auch direkt explizit! Man sollte immer versuchen alles so simpel wie möglich zu halten, nicht nur bei der SW-Entwicklung. Versuche jede Lösung mit gerade dem Minimum an Komplexität zu realisieren den das Problem zulässt!
damit fällt dann auch Multithreading auf mehreren Cores weg. Denn damit holt man sich nen Haufen Probleme und die Komplexität steigt auch nicht ganz unwesentlich.
Das stimmt doch gar nicht, man muss in der Design-Phase nur das nötige Maß an Umsicht walten lassen dann bringt Multithreading fast keine zusätzliche Komplexität mit sich. Es gibt bestimmt auch Probleme die sich mit Multithreading leichter lösen lassen als ohne Multithreading.
Wird für Rendevouz-Funktionen genutzt (z.B. TSCs synchronisieren) und dafür alle außer der sendenden CPUs anzuhalten.
Wofür willst Du alle CPUs anhalten? Planst du noch andere Dinge für IPI?
Ich frage so hartnäckig weil ich auf meiner Plattform gar keine Möglichkeit habe eine bestimmte CPU zu unterbrechen aber viele OSe bei SMP eben so eine Möglichkeit erwarten und deswegen möchte ich vorher an alle Eventualitäten denken damit ich hinterher nichts vergessen hab.
Darum ging es aber garnicht - dies sind nur Möglichkeiten, ohne unterbrechbaren Kernel auf x86 auszukommen.
Ich denke ob man einen unterbrechbaren Micro-Kernel benötigt oder nicht hängt eher vom Kernel-Design ab und weniger von der darunter liegenden Hardware. Mal von den TLB-Flushs abgesehen benötigt man IMHO auch bei x86 keinen unterbrechbaren Micro-Kernel.
Grüße
Erik
-
Das Problem das Du Pages bereits im Frei-Pool hast die aber eventuell noch in TLBs einiger/anderer CPUs drin sind muss aber gelöst werden indem Du alle TLBs löscht bevor die Pages in den Frei-Pool kommen. Das senden der IPIs und warten auf alle Antworten muss also in der Mitte von vmmUnmap() passieren und nicht erst hinterher.
So wie du dir das denkst funktioniert das bei mir nicht. Ich hatte doch mal ne vereinfachte Variante von meiner vmmUnmap/vmmMap geschrieben.
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.
Diese Situation tritt natürlich sehr sehr selten auf.
Solange ich aus der vmmMap/vmmUnmap Funktion noch nicht rausbin, sind die Pages praktisch noch nicht in Verwendung. Also kann ich das TLB Löschen auch hinterher machen (aber ich gebe den Lock erst frei, wenn die Nachricht versendet ist).
Es ist halt wieder ne Performance-Frage, ich meine stell dir vor, es sollen 20 Pages geunmappt werden, da wäre es sehr schlecht wenn du auch 20 IPIs versendest und dann auch noch wartet müsstest bis die anderen CPUs ihr IPIs abgearbeitet haben!
Ich bestreite nicht das Du Dir Mühe gibst aber aus Deinen vergangenen Problembeschreibungen habe ich den subjektiven Eindruck gewonnen das Dir da etwas an Erfahrung fehlt und Du deswegen verschiedene Probleme nicht so deutlich/frühzeitig erkennst.
Richtig, an Erfahrung mangelt es mir, besonders was das Programmieren von Anwendungen betrifft. Meine Programmiererfahrung beschränkt sich leider nur auf das OS Programmieren.
Du solltest mal ganz klar definieren was ein Bug ist und dann Code schreiben der zur Laufzeit (in der Debug-Version) nach genau dieser Bedingung prüft. Mit diesem Weg kommst Du zu recht präzisen Debug-Meldungen, zumindest bin ich bis her damit recht gut gefahren.
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!
Jedes mal wenn Du einen Deadlock hast musst Du die Ursache heraus finden und dann wird Dein Code mit jedem beobachteten Deadlock besser.
Und genau hier ist doch das Problem. Ich kann nur Bugs fixen die ich "nachstellen" kann (das ist das größte Problem von Bugs eines OSs). Ein Deadlock der nur sporadisch auftritt und nach keinem Muster zu "fangen" ist, wie willst du da raus bekommen, in welcher Lock jemand war und welche Lock er bekommen wollte.
Was ich damit sagen will, stell dir vor du hast ein tolles OS geschrieben und das wird halt ausgeführt (ohne Debug-Msgs) und das bleibt halt von Zeit zur Zeit an immer einer anderen Stelle hängen und du als Entwickler kannst die Situation nicht nachstellen. Das kann alles sein, von Hardware-Problem bis irgendein Lockingfehler der schwer zu finden ist.
Klar gibt es ein paar zusätzliche Schwierigkeiten aber die sind IMHO nicht unlösbar.
Von unlösbar redet ja auch keiner, nur schwierig zu lösen ;)
Das stimmt doch gar nicht, man muss in der Design-Phase nur das nötige Maß an Umsicht walten lassen dann bringt Multithreading fast keine zusätzliche Komplexität mit sich.
Fairerweise muss man schon mal sagen, wer macht denn ne wirkliche Design-Phase (mal von dir und deiner Hardware abgesehen)?
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.
Und ich als Hobbyprogrammieren/Anfänger werde mich bestimmt nicht vorher hinsetzen und ein Design anfertigen. Denn dann würde ich heute noch immer keinen Kernel haben, weil ich mich mit Dingen beschäftigen würde, von denen ich keine Ahnung habe und ohne Praxis auch nie haben werde.
Wofür willst Du alle CPUs anhalten? Planst du noch andere Dinge für IPI?
Anhalten will ich sie nur im Falle einer Kernel-Exception (damit die nicht alle ne for(;;); Schleife abarbeiten) und wenn der PC runtergefahren wird. Ansonsten könnte man noch die Möglichkeit geben, CPUs zur Laufzeit "abzuschalten", aber wozu das gut sein soll weiß ich nicht.
Ich habe halt z.B. mit der Rendevouz-Funktion versucht mein IPI System möglichst nutzbar zu machen, keine Ahnung ob ich das später noch für was anderes als TSC synchronisieren nutzen werde.
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.
Mal von den TLB-Flushs abgesehen benötigt man IMHO auch bei x86 keinen unterbrechbaren Micro-Kernel.
Wenn du den Kernel mit einem GIANT_LOCK schützt brauchst du nichtmal dafür nen unterbrechbaren MikroKernel.
-
Also die NMI Variante hat sogar noch den Vorteil, das dadurch mein CPU anhalten Code erst richtig funktioniert. Denn vorher ist immer mind. 1 CPU (B) in einer "endlos" Schleife hängen geblieben, da eine CPU (A) ne Exception ausgelöst hat und genau diese CPU (A) hat den Lock den die andere CPU (B) versucht zu bekommen und da die CPU (B) meistens die Ints aus hat, hat sie halt die IPI Nachricht nie bekommen, aber jetzt mit dem NMI klappt das wunderbar.
Jetzt kann ich auch endlich mal nen Bug fixen, der sonst so selten aufgetreten ist, das ich ihn nie reproduzieren konnte, jetzt klappt es öfter :D
Was noch gar nicht diskutiert wurde, hat denn die NMI Variante irgendwelche Nachteile?
-
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
-
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?).
-
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
-
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".
-
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ß
-
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
-
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.
-
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
-
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 ;)
-
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
-
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) ;)
-
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ß
-
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
-
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.
-
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.
-
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
-
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 ;) ).
-
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.
-
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.
-
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
-
Du versuchst da Äpfel mit Birnen zu vergleichen.
Möglich.
Aber wenn Du in einem Stück Software einen Fehler findest dann kannst Du den beheben und neu compilieren und gut is.
Ich vermute mal das es schon soetwas gibt, dass man um irgendwelche Fehler in irgendeiner Software drumrumprogrammiert.
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).
Logisch und nicht mein Problem.
Wenn man nur den BKL (wie ich übrigens vorhin lesen durfte, gibt es den ja immernoch) nutzt hat man natürlich ein leichtes Leben.
Ich habe aber halt viele Locks und da kommt dann durchaus mal die Situation auf das Thread A den Lock 1 hat und Lock 2 versucht zu bekommen. Thread B hat Lock 2 und will Lock 1 und solche Situationen sind ab einer gewissen Größe schlecht zu überschauen (jetzt komm mir ja nicht mit Dokumentation ;) ).
Das ist so "meine" Quelle für Deadlocks, vorallem welche die sich schlecht bis gar nicht finden lassen (da sie nie auftreten oder so selten das man sie nicht reproduzieren kann).
-
Hallo,
Ich vermute mal das es schon soetwas gibt, dass man um irgendwelche Fehler in irgendeiner Software drumrumprogrammiert.
Sicher gibt es das, es gibt ne Menge schlechter Manager die einem zu knappe Zeitpläne aufdrücken und es gibt ja auch noch schlechte Programmierer.
Logisch und nicht mein Problem.
Na scheinbar ist das doch Dein Probem, wie Du ja selber schreibst.
da kommt dann durchaus mal die Situation auf das Thread A den Lock 1 hat und Lock 2 versucht zu bekommen. Thread B hat Lock 2 und will Lock 1
Genau das darf es nicht geben! Das ist fehlerhafter Code. Es darf absolut keinen Ausführungspfad geben der zu so einer Situation führen kann (genau dafür hätte ich gerne ein Toll das sowas automatisch prüft).
und solche Situationen sind ab einer gewissen Größe schlecht zu überschauen (jetzt komm mir ja nicht mit Dokumentation ;) ).
Doch, ich komme Dir jetzt mit Dokumentation und Planung. Wenn Du eben solche Probleme vermeiden willst dann musst Du Dir angewöhnen sauberer zu programmieren und dazu gehört immer auch ne anständige Dokumentation, vor allem bei etwas so komplexen wie einem SMP-OS-Kernel. Wenn Du Deine SW gut dokumentierst und planst wirst Du merken das sich solche Probleme relativ einfach entdecken lassen, noch bevor Du den Compiler anwirfst. Du bekommt dadurch einen viel besseren Überblick, probiere es doch mal aus.
Grüße
Erik
-
Na scheinbar ist das doch Dein Probem, wie Du ja selber schreibst.
Wo? Ich meine es geht darum das man Lock 1 bekommt, dann Lock 2 und nicht erst Lock 1 sondern Lock 2 freigibt, oder? Man gibt die Locks nach dem LIFO-Prinzip wieder frei.
Daran halte ich mich!
Du bekommt dadurch einen viel besseren Überblick, probiere es doch mal aus.
Dokumentation, ist für mich das selbe wie Zwischenergebnisse in der Schule ;) Die habe ich meistens auch nicht aufgeschrieben.
Ich hatte mal mit ner Dokumentation angefangen, wo ich beschrieben habe was die Parameter machen/beinhalten, aber ich habe irgendwann festgestellt, das ich einfach nur aus nem alles sagenden Namen nen Satz gemacht habe, also zwecklos.
Was ich machen müsste, ist die Funktionalität einer Funktion zu beschreiben, aber auch das kann man bei mir aus dem Namen ableiten, bleibt nur noch das ich aufschreiben sollte, welche Locks benutzt werden.
Dann müsste ich mind. einmal (zu Dokumentationszwecken) alle meine Funktionen mit allen Funktionsaufrufen durchgehen um herauszufinden welche das sind.
Vielleicht mache ich das sogar, habe ich wenigstens was zu tun ;)
-
Hallo,
Ich meine es geht darum das man Lock 1 bekommt, dann Lock 2 und nicht erst Lock 1 sondern Lock 2 freigibt, oder? Man gibt die Locks nach dem LIFO-Prinzip wieder frei.
Das Du das LIFO-Prinzip beim locken -- entlocken einhältst habe ich nicht bezweifelt.
Dein Problem ist das es Code gibt der erst Lock 1 und dann Lock 2 will und das es ebenfalls Code gibt der erst Lock 2 und dann Lock 1 will. Genau das ist ein Bug! Sowas führt zu Deadlocks und muss 100%-tig vermieden werden!
Dokumentation, ist für mich das selbe wie Zwischenergebnisse in der Schule ;) Die habe ich meistens auch nicht aufgeschrieben.
Das mag in der Schule noch funktionieren (ich hab das auch nur selten gemacht und auch ein paar mal deswegen ne schlechtere Note bekommen obwohl das Ergebnis richtig war) aber bei großen Projekten, und ein OS ist ein großes Projekt, kann man sich solche Schlampigkeiten nicht leisten. Sonst endet man genau da wo Du jetzt bist und ärgert sich mit sporadischen Deadlocks rum.
....
Vielleicht mache ich das sogar, habe ich wenigstens was zu tun ;)
Mach das. Vielleicht lernst Du dabei sogar das gut strukturierte Arbeit viel effizienter geht. ;)
Grüße
Erik
-
Dein Problem ist das es Code gibt der erst Lock 1 und dann Lock 2 will und das es ebenfalls Code gibt der erst Lock 2 und dann Lock 1 will. Genau das ist ein Bug! Sowas führt zu Deadlocks und muss 100%-tig vermieden werden!
Richtig.
Das Problem was ich mit meiner sporadischen Deadlock hatte, war ein wenig komplexer und ließ sich im Endeffekt nur dadurch lösen das ich jetzt IPI-Nachrichten per NMI schicke.
Da hatte eine CPU (A) den Lock 1 und wollte Lock 2 haben. Lock 2 hatte habe ne andere CPU (B) und diese hat ne IPI-Nachricht gesendet und darauf gewartet das CPU A die Nachricht abarbeitet, das konnte aber nie passieren, weil CPU A noch Lock 1 hatte und damit die Ints auswaren. Ich weiß nicht ob das nen klassischer Deadlock ist, weil die Locks ansich haben erstmal nichts mit einander zu tun, nur die Tatsache der ausgeschalteten Ints war ein Problem.
(ich hab das auch nur selten gemacht und auch ein paar mal deswegen ne schlechtere Note bekommen obwohl das Ergebnis richtig war)
Wenn ich es nicht besser wüsste, würde ich sagen wir hatten die gleichen Lehrer ;)
Mach das. Vielleicht lernst Du dabei sogar das gut strukturierte Arbeit viel effizienter geht.
Das kann ich dir ja dann erzählen.
Aber auch ne Dokumentation hilft nicht, wenn man Fehler an der falschen Stelle sucht ;) (War mein Problem, habe alles auf ne Deadlock geschoben, aber der Code hatte nen Fehler)
-
Dir geht es darum, Locks ohne Schaden entziehen zu dürfen.
Auch, aber die ReadWrite-Sache könnte unter Umständen der Performance helfen.
Nein, dein Ausgangspunkt war das schadenfreie Entziehen von Locks!
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.
Ich habe mich damit nicht befasst, aber du kannst ein Problem, welches eine Zugriffssperre erfordert, nicht ohne Zugriffssperre umgehen. Das ist in der Natur der Sache.
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.
Den zweiten Teilsatz lesen können? ...oder schlecht reproduzierbar durch Race Conditions, also ungenügend/schlecht geschützte Strukturen...
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.
Schlug ich bereits vor, nennt man GIANT_LOCK. Funktioniert und ist schneller als CPU-Festpinnen. Langsamer als gute Granularität.
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.
Ich als Anwendungsprogrammierer muss damit leben, richtig. Ich als Systembesitzer ziehe mir (in der Theorie) ein BIOS-Update. Dieses BIOS-Update aktualisisiert mir bei jedem Systemstart den CPU-Mikrocode und fixt damit das Problem. Ich als Betriebssystementwickler stelle eine solche Schnittstelle dem Systembesitzer zur Verfügung, sodaß dieser die aktualisierten Mikrocodes auch ohne BIOS-Update einspielen kann.
Der Blödsinn liegt darin begründet, dass du grundlos Sympthombehebung durchführst. Ein CPU-Bug lässt dir keine andere Wahl, es sei denn du baust die CPU selbst.
Aber wenn Du in einem Stück Software einen Fehler findest dann kannst Du den beheben und neu compilieren und gut is.
Ich vermute mal das es schon soetwas gibt, dass man um irgendwelche Fehler in irgendeiner Software drumrumprogrammiert.
Korrekt. Besonders in Produktionsumgebungen, wo man stabile und bekannte Softwareversionen benötigt, wird das so getan. Allerdings trifft das nur dann zu, wenn die zu benutzende Software nicht selbstgeschrieben ist. Kurz: Wenn möglich, wird gefixt. Erst wenn unmöglich oder nicht mehr sinnvoll, wird mit Workarounds gearbeitet.
Ich habe aber halt viele Locks und da kommt dann durchaus mal die Situation auf das Thread A den Lock 1 hat und Lock 2 versucht zu bekommen. Thread B hat Lock 2 und will Lock 1 und solche Situationen sind ab einer gewissen Größe schlecht zu überschauen (jetzt komm mir ja nicht mit Dokumentation ;) ).
Dann solltest du vielleicht dokumentieren, wie du dir gewisse Dinge vorstellst oder es einfach direkt richtig machen. Wenn (b) nicht geht, musst du halt doch (a) machen.
Wenn du weißt, dass dein Design kaputt ist, warum machst du dann keins, welches weniger kaputt ist?
Das ist so "meine" Quelle für Deadlocks, vorallem welche die sich schlecht bis gar nicht finden lassen (da sie nie auftreten oder so selten das man sie nicht reproduzieren kann).
Das nennt man Race-Condition.
Na scheinbar ist das doch Dein Probem, wie Du ja selber schreibst.
Wo? Ich meine es geht darum das man Lock 1 bekommt, dann Lock 2 und nicht erst Lock 1 sondern Lock 2 freigibt, oder? Man gibt die Locks nach dem LIFO-Prinzip wieder frei.
Daran halte ich mich!
Offensichtlich nicht immer oder nicht gut genug. Und wenn CPU1 erst Lock 1 und dann Lock 2 anfragt und CPU2 genau umgekehrt, dann hast du ein anderes wichtiges Prinzip verletzt.
Ich hatte mal mit ner Dokumentation angefangen, wo ich beschrieben habe was die Parameter machen/beinhalten, aber ich habe irgendwann festgestellt, das ich einfach nur aus nem alles sagenden Namen nen Satz gemacht habe, also zwecklos.
Was ich machen müsste, ist die Funktionalität einer Funktion zu beschreiben, aber auch das kann man bei mir aus dem Namen ableiten, bleibt nur noch das ich aufschreiben sollte, welche Locks benutzt werden.
Blödsinn. Was offensichtlich ist, muss man nicht unbedingt dokumentieren. Du erklärst Programme ja hoffentlich auch nicht mehr zeilenweise?
Wie wäre es mit einer Block-Übersicht, die die einzelnen Abhängigkeiten der Einzelteile untereinander dokumentiert? Genau diese Abhängigkeiten (=Schnittstellen) musst du definieren. Das machst du rekursiv von oben und soweit wie nötig. Also die einzelnen Blöcke wieder soweit einzeln dokumentieren, bis man den Überblick wieder hat. Zu den Schnittstellen gehören die zu schützenden Datenstrukturen (soweit vorhanden) und daraus ergibt sich innerhalb einer Ebene auf einen Blick, welche Locks wo verwendet werden.
Und sowas macht man parallel mit dem Projekt - geht einfach und schnell nebenher, wenn etwas funktioniert - , bei verteilten Großprojekten macht man das vorher in der Designphase.
Aber auch ne Dokumentation hilft nicht, wenn man Fehler an der falschen Stelle sucht ;) (War mein Problem, habe alles auf ne Deadlock geschoben, aber der Code hatte nen Fehler)
Darum dokumentiert man. Entweder, um gewisse Fehler von vornherein ausschließen zu können (oder stark eingrenzen zu können), oder um "mal schnell" in der Logik nachzuschauen, ob das überhaupt so geht. Die Logikprüfung muss immer aus der Vogelperspektive sehen, denn selbst wenn alle Einzelteile logisch fehlerfrei sind, muss es das Gesamtsystem noch lange nicht sein.
Gruß,
Svenska
-
Schlug ich bereits vor, nennt man GIANT_LOCK.
Dann hast du mich nicht richtig verstanden, ich meinte nicht einen GIANT_LOCK, sondern viele kleine Locks, aber man darf immer nur eine dieser Locks zur gleichen Zeit haben!
Wenn du weißt, dass dein Design kaputt ist, warum machst du dann keins, welches weniger kaputt ist?
Weil mir kein besseres einfällt ;) (was mir gefällt/zusagt)
Ihr könnt mir aber gerne eins vorschlagen und ich sage dann was mir nicht gefällt ;)
-
Damit schützt du dann die vielen kleinen Locks selbst durch ein gigantisches Locking-Lock. Ist also ein GIANT_LOCK.
-
Hallo,
Weil mir kein besseres einfällt ;) (was mir gefällt/zusagt)
Wenn Du jemals zum Ziel (SMP fähiges OS) kommen willst sollte Dir aber eines ohne Deadlocks gefallen/zusagen! ;)
Grüße
Erik
-
Damit schützt du dann die vielen kleinen Locks selbst durch ein gigantisches Locking-Lock. Ist also ein GIANT_LOCK.
Häh?! Ich will die Locks nicht durch einen großen Lock schützen (wäre auch totaler unfug), sondern ich müsste halt meine Datenstrukturen und Algorithmen so auslegen, das du immer nur einen Lock zur gleichen Zeit haben darfst/kannst. Es gibt trotzdem viele verschiedene Locks.
Wenn Du jemals zum Ziel (SMP fähiges OS) kommen willst sollte Dir aber eines ohne Deadlocks gefallen/zusagen!
Meine Deadlocks bin ich ja losgeworden (bis wieder eins auftritt ;) ). Ich finde mein Design gar nicht so schlecht, aber ihr könnt halt gerne andere Vorschlagen. Mein "Problem" ist im Endeffekt ja "nur" der VMM bzw. habe ich das ja jetzt im Griff.
-
Damit schützt du dann die vielen kleinen Locks selbst durch ein gigantisches Locking-Lock. Ist also ein GIANT_LOCK.
Häh?! Ich will die Locks nicht durch einen großen Lock schützen (wäre auch totaler unfug), sondern ich müsste halt meine Datenstrukturen und Algorithmen so auslegen, das du immer nur einen Lock zur gleichen Zeit haben darfst/kannst. Es gibt trotzdem viele verschiedene Locks.
Okay, also wenn du sagst "Du darfst nur ein Lock zur gleichen Zeit haben", dann ist das eine Policy, weil es nicht erzwungen wird. Ein böswilliger Angreifer könnte somit durch einen Treiber dein System in ein Deadlock bringen (oder wenn du es irgendwann vergisst und selbst Deadlocks produzierst).
Wenn du sagst "Du kannst nur ein Lock zur gleichen Zeit haben", fallen mir da nur zwei Möglichkeiten ein.. entweder es gibt nur ein Lock systemweit (giant lock) oder es gibt viele kleine Locks, wie von dir vorgeschlagen. Um durchzusetzen, dass du nur eins haben kannst, musst du also die Locks selbst schützen, was auf den ersten Ansatz hinausläuft.
Wenn du sagst "Du brauchst zu jedem Zeitpunkt nur ein Lock", dann ist das schön, aber ich glaube nicht immer machbar (das ist ebenfalls eine Art giant lock, nur ohne Performance-Verlust, weil alles darauf ausgelegt ist).
Oder ich versteh deinen Gedankengang nicht.
Gruß
-
Ich hab zwar den Thread nicht gelesen, aber habe zu dem ganzen Thema zwei Anmerkungen:
* Es gibt lockfreie Algorithmen für mehrere Datenstrukturen, für einen Stack und eine Queue sind die m.E. nach ziemlich einfach. Es gibt auch eine für einen std::vector (ohne Iteratoren) und ich hab gelesen dass es welche für einen Baum, eine Hashmap und eine Deque gibt. Man muss dabei allerdings aupassen, da die meisten der Originalalgorithmen garbage collection voraussetzen und erst durch Anwendung von hazard pointern auch ohne garbage collection korrekt implementierbar sind. Ein damit zusammenhängendes, sehr subtiles Problem ist das ABA-Problem. (Alle vorkommenden unbekannten Sachen sollten googlebar sein, aber ich kann natürlich auch gerne mehr dazu sagen, falls Interesse besteht)
* Wenn man a priori weiß in welcher Reihenfolge Locks gehalten werden können, dann kann man jedem Lock eine Nummer geben und beim holen des Locks überprüfen, ob die max. Nummer aller momentan gehaltenen Locks kleiner als die des neuen Locks ist und falls nicht, eine Fehlermeldung ausgeben. Das könnte eventuell das Debuggen erleichtern.
-
Wenn du sagst "Du kannst nur ein Lock zur gleichen Zeit haben", fallen mir da nur zwei Möglichkeiten ein.. entweder es gibt nur ein Lock systemweit (giant lock) oder es gibt viele kleine Locks, wie von dir vorgeschlagen. Um durchzusetzen, dass du nur eins haben kannst, musst du also die Locks selbst schützen, was auf den ersten Ansatz hinausläuft.
Nicht wirklich. Der Unterschied ist, gegen wen du die Locks schützt. Wenn du einen Lock für die Locks hättest, würdest du anderen Threads verbieten, einen Lock zu holen, während du gerade einen hast. Wenn ich es richtig verstanden habe, will FlashBurn aber nur dem eigenen Thread verbieten, einen zweiten Lock zu nehmen - das läuft dann nicht mehr unter Locks locken, sondern ist irgendein anderer Mechanismus. Ein ziemlich trivialer sogar: lock() muss thread->current_lock setzen und wenn es schon gesetzt war, gibt es einen Panic.
-
Wenn ich es richtig verstanden habe, will FlashBurn aber nur dem eigenen Thread verbieten, einen zweiten Lock zu nehmen
Wenigstens einer der mich verstanden hat ;)
Ich meine wirklich das man halt in einer Funktion nur einen Lock haben darf und dann auch keine andere Funktion aufrufen darf (ohne den Lock freizugeben), die wieder nen Lock haben will.
Ein böswilliger Angreifer könnte somit durch einen Treiber dein System in ein Deadlock bringen (oder wenn du es irgendwann vergisst und selbst Deadlocks produzierst).
Zu monolithisch gedacht. Wenn mein Kernel sich an meine Regeln hält läuft das erstmal alles. Was dann in den Treibern passiert ist ne ganz andere Sache. Da kannst du im Prinzip Deadlocks nicht verhindern (wenn man davon ausgeht, das man den Treiber nicht selbst geschrieben hat). Zumal der Vorteil eines Mikrokernels dann genau das ist, das während einer Lock die Ints nicht deaktiviert werden können (ja, ich weiß könnte man auch im Kernel machen, aber wozu?).
Oder ich versteh deinen Gedankengang nicht.
Ich hoffe du verstehst es jetzt ;)
Ich will diesen Ansatz (nur ein Lock zur gleichen Zeit) ja auch nicht per Gewalt durchsetzen, sondern das sollte halt einfach ne Programmierregel sein, dass das schwer bis eventuell sogar gar nicht durchzusetzen ist, steht auf einem anderen Blatt.
aber ich kann natürlich auch gerne mehr dazu sagen, falls Interesse besteht
Ich denke wir alle wären an mehr Informationen oder Hinweise in der Richtung Algos ohne Locks sehr interessiert.
-
Hmm, klingt nachvollziehbar. Ich mag Threading nicht, das ist mir alles zu verwurstet. :-p
Um das umzusetzen müsstest du aber zu jeder Funktion dokumentieren, ob sie ein Lock braucht (was nicht immer vorhersehbar ist) und das darf sich ja dann auch nicht nachträglich ändern. Unschön, aber machbar.
Was machst du aber, wenn du einen Anwendungsfall hast, für den du zwei Locks brauchst (z.B. einmal die PCI-Datenstrukturen und einmal die Puffer-/Speicherstrukturen zur Übergabe der Daten der Netzwerkkarte)?
Ich weiß nicht, ob sich das durch eine so simple Policy lösen lässt. (Besonders nicht, wenn die Policy als Workaround für ein schlechtes Design eingeführt wurde.)
-
Ich weiß nicht, ob sich das durch eine so simple Policy lösen lässt. (Besonders nicht, wenn die Policy als Workaround für ein schlechtes Design eingeführt wurde.)
Also erstmal lässt sich diese Policy nicht wirklich umsetzen, da man immer irgendwo mind. 2 Locks zur gleichen Zeit hat/braucht.
Und mein "schlechtes" Design hatte halt "nur" das Problem das ich nicht wusste wie man IPI-Nachrichten an CPUs sendet die die Ints aus haben (was ja inzwischen gelöst ist).
Mich würde aber auch mal interessieren wie andere OSe das lösen.
-
Hallo,
aber ich kann natürlich auch gerne mehr dazu sagen, falls Interesse besteht)
Ein klein wenig mehr wäre schon nicht schlecht. Das Problem was ich bei vielen dieser lock-freien Datenstrukturen vermute ist das diese wohl nicht immer sehr effizient zu durchsuchen sind oder andere Nachteile haben. Eine doppelt verkettete Liste geht IMHO nicht lock-frei aber man kann recht effizient darin navigieren und sie bietet ein gewisses Maß an zusätzlicher Sicherheit wegen der Redundanz bei den Pointern. Die Frage ist natürlich wie schwerwiegend diese eventuellen Nachteile der lock-freien Datenstrukturen überhaupt sind.
Ich mag Threading nicht, das ist mir alles zu verwurstet. :-p
Bist wohl Vegetarier wenn Du nichts verwurstetes magst? Also ich mag Threading sehr, da ist alles so schön parallel. :-D
Um das umzusetzen müsstest du aber zu jeder Funktion dokumentieren, ob sie ein Lock braucht (was nicht immer vorhersehbar ist) und das darf sich ja dann auch nicht nachträglich ändern. Unschön, aber machbar.
Das sollte man bei einem Projekt, wie einem OS-Kernel, aber immer sauber dokumentieren. Klar macht das Arbeit, aber es ist IMHO nicht "unschön".
Ich weiß nicht, ob sich das durch eine so simple Policy lösen lässt.
Mit an Sicherheit grenzender Wahrscheinlichkeit nicht, wenn man keinen GIANT-Lock will sondern viele kleine Locks dann wird man ganz sicher mal vor der Notwendigkeit stehen mehrere davon haben zu müssen.
(Besonders nicht, wenn die Policy als Workaround für ein schlechtes Design eingeführt wurde.)
lol, besser hätte ich das auch nicht formulieren können.
Und mein "schlechtes" Design hatte halt "nur" das Problem das ich nicht wusste wie man IPI-Nachrichten an CPUs sendet die die Ints aus haben (was ja inzwischen gelöst ist).
Ich würde schon sagen das Dein Design schlecht oder zumindest fehlerhaft ist/war.
Siehe:Da hatte eine CPU (A) den Lock 1 und wollte Lock 2 haben. Lock 2 hatte habe ne andere CPU (B) und diese hat ne IPI-Nachricht gesendet und darauf gewartet das CPU A die Nachricht abarbeitet, das konnte aber nie passieren, weil CPU A noch Lock 1 hatte und damit die Ints auswaren. Ich weiß nicht ob das nen klassischer Deadlock ist, weil die Locks ansich haben erstmal nichts mit einander zu tun, nur die Tatsache der ausgeschalteten Ints war ein Problem.
Das Problem steckt in den ersten 20 Worten. Das jemand Lock 2 hat ohne Lock 1 zu haben obwohl an anderer Stelle Lock 2 nur innerhalb von Lock 1 benutzt wird und dann gegenseitige Abhängig auftritt ist ein Bug/Deadlock. Sowas darf es nicht geben! Diesmal hat das die Benutzung der IPIs blockiert (das konntest Du per NMI lösen) aber in einer anderen Situation, wo Du wieder vor einem derartigen Deadlock stehst, lässt sich das vielleicht nicht so einfach lösen. Das es überhaupt 2 verschieden Pfade gibt um an Lock 2 zu kommen, einmal mit Lock 1 und einmal ohne, das ist Dein Problem!
Grüße
Erik
-
Ich würde schon sagen das Dein Design schlecht oder zumindest fehlerhaft ist/war.
Ich kann mit Kritik leben, dann aber bitte auch konstruktiv!
Ich denke dafür wäre aber mal wieder ein neuer Thread nötig, aber nur wenn interesse darin besteht mal ein VMM Design zu diskutieren!?
Das es überhaupt 2 verschieden Pfade gibt um an Lock 2 zu kommen, einmal mit Lock 1 und einmal ohne, das ist Dein Problem!
Lässt sich wie du schon weiter oben mal geschrieben hattest, leider nicht (oder nicht so einfach??) vermeiden.
Ein ähnlicher Fall wäre, dass 2 Prozesse ne Page gemappt haben und dafür haben sie unterschiedliche Locks (weil 2 unterschiedliche Adressräume) und dann wollen beide den Lock um die IPI-Nachricht zu senden. Also ist es gar nicht so ungewöhnlich auf 2 Wegen an ein und die selbe Lock zu kommen (das ist woanders auch noch so)!
Ein weiteres Bsp. wäre, dass man nen Lock für irgendeine Datenstruktur hat und dann neuen Speicher braucht und ne Page mappt, dann hast du einmal den Lock für die jeweilige Datenstruktur und einmal willst du den gleichen Lock für den Adressraum haben.
-
Das es überhaupt 2 verschieden Pfade gibt um an Lock 2 zu kommen, einmal mit Lock 1 und einmal ohne, das ist Dein Problem!
Öhm, wenn ich mal eine ganz blöde Frage stellen darf: Wenn man Lock 2 nur nehmen dürfte, wenn man Lock 1 auf jeden Fall schon hat, wäre dann Lock 2 nicht überflüssig? Und wenn man es nur nehmen darf, wenn man keinen anderen Lock hat, ist man wieder bei FlashBurns Policy.
-
Hallo,
Ich kann mit Kritik leben, dann aber bitte auch konstruktiv!
Sorry, aber ich bin schon der Meinung das meine Kritik "konstruktiv" war, ich hab doch unmittelbar darunter präzise erläutert worin ich das Problem sehe. Wenn Du bezüglich des von mir erläuterten Problems anderer Meinung bist dann musst Du mir das erklären oder wir können das auch gerne (in einem anderen Thread) anhand von konkretem Code diskutieren. Ich wollte Dir einfach nur erläutern warum ich der Meinung bin das Du Locks falsch benutzt.
Das es überhaupt 2 verschieden Pfade gibt um an Lock 2 zu kommen, einmal mit Lock 1 und einmal ohne, das ist Dein Problem!
Lässt sich wie du schon weiter oben mal geschrieben hattest, leider nicht (oder nicht so einfach??) vermeiden.
Wo hab ich auch nur angedeutet das es unmöglich (oder auch nur schwierig) wäre Locks immer in der selben Reihenfolge zu holen? Ich hab geschrieben das es bei vielen Locks sicher auch mal Notwendig ist mehrere zu haben aber ich hab nicht geschrieben das es unmöglich (oder schwierig) ist diese in geordneter Reihenfolge zu holen.
Ein ähnlicher Fall wäre, dass 2 Prozesse ne Page gemappt haben und dafür haben sie unterschiedliche Locks (weil 2 unterschiedliche Adressräume) und dann wollen beide den Lock um die IPI-Nachricht zu senden.
Das ist ein Problem weil der Lock für die IPI-Benutzung eben indirekt verlangt das keine anderen Locks (mit gesperrten INTs) in Benutzung sind. Ich muss zugeben das IPI da schon ein gewisser Sonderfall ist, sowas hab ich auf meiner Plattform nicht und daher hab ich mir darüber noch nicht den Kopf zerbrochen. Die IPIs als NMI zu realisieren erscheint mir als guter Ausweg aus diesem Dilemma (im Prinzip mache ich das ja auch so indem ich diese Dinge direkt in HW abarbeite und in Kauf nehme das die gerade laufende SW dadurch kurzzeitig eventuell blockiert/verlangsamt wird) aber es schränkt auch ganz klar die Möglichkeiten der IPI-Handler ein (was aber wohl kein Problem ist).
Also ist es gar nicht so ungewöhnlich auf 2 Wegen an ein und die selbe Lock zu kommen (das ist woanders auch noch so)!
Dann dürftest Du noch ne Menge anderer verborgener Deadlocks in Deinem Code haben. Sorry, aber das sehe ich als eine "Schwäche" Deines Designs.
Ein weiteres Bsp. wäre, dass man nen Lock für irgendeine Datenstruktur hat und dann neuen Speicher braucht und ne Page mappt, dann hast du einmal den Lock für die jeweilige Datenstruktur und einmal willst du den gleichen Lock für den Adressraum haben.
Solange die Wege zu den einzelnen Locks keine Deadlocks produzieren sehe ich da kein Problem.
Siehe mal nach http://de.wikipedia.org/wiki/Deadlock (http://de.wikipedia.org/wiki/Deadlock) (auch die Links sind recht interessant), dort ist "Circular Wait ausschließen" das richtige Stichwort. In dem von Dir (am Freitag) geschildertem und von mir kritisiertem IPI-Szenario hast Du eben genau so ein "Circular Wait".
Öhm, wenn ich mal eine ganz blöde Frage stellen darf: Wenn man Lock 2 nur nehmen dürfte, wenn man Lock 1 auf jeden Fall schon hat, wäre dann Lock 2 nicht überflüssig?
Hm, das ist ein berechtigter Einwand (und keine blöde Frage). Muss ich (oder besser wir alle) mal in Ruhe drüber nachdenken.
Grüße
Erik
-
Ich hab geschrieben das es bei vielen Locks sicher auch mal Notwendig ist mehrere zu haben aber ich hab nicht geschrieben das es unmöglich (oder schwierig) ist diese in geordneter Reihenfolge zu holen.
Und genau das mit der Reihenfolge hatten wir doch schon, läuft nach dem LIFO Prinzip. Das andere was du noch meinst ist das Problem das mehrere Pfade zu dem gleichen Lock führen und wie taljeth schon geschrieben hat, wenn du alle Locks immer nur auf einem Pfad holen darfst, brauchst du die ganzen Locks nichts!
Die Locks sind dazu da kleine und möglichst kurze kritische Bereiche, die von mehreren Threads genutzt werden können (und genau das ist der Punkt!), zu schützen.
Solange die Wege zu den einzelnen Locks keine Deadlocks produzieren sehe ich da kein Problem.
Wieso siehst du dort mit einmal kein Problem? Ist doch das gleiche Prinzip, das mehrere Pfade zu einem Lock führen.
-
Ich glaube schon, dass erik nicht ganz falsch liegt, aber er schränkt es zu sehr ein: Wenn es nur auf einem Pfad passieren kann, ist der zweite Lock überflüssig.
Die eigentliche Bedingung müsste irgendwie so aussehen: Ein Codepfad, der Lock 1 nicht geholt hat, aber Lock 2 holt, darf nicht versuchen, Lock 1 zu holen während er Lock 2 noch hält.
-
Hallo,
Die eigentliche Bedingung müsste irgendwie so aussehen: Ein Codepfad, der Lock 1 nicht geholt hat, aber Lock 2 holt, darf nicht versuchen, Lock 1 zu holen während er Lock 2 noch hält.
Genau so muss diese Bedingung lauten, alles andere läuft in einen "Circular Wait"!
Einen derartigen "Circular Wait" hatte FlashBurn durch seine vorherige IPI-Implementierung (ohne NMI) erzeugt.
Das Problem mit vielen Locks ist eben das man da höllisch aufpassen muss das die einzelnen Code-Pfade nicht zum Problem werden. Da FlashBurn ja schrieb das er ne Menge Henne-Ei-Probleme in seinem Code hat (wo sich verschiedene Code-Teile gegenseitig im Kreis aufrufen) dürften da eventuell noch ne Menge Deadlocks, mit "Circular Wait", lauern.
Grüße
Erik
-
dürften da eventuell noch ne Menge Deadlocks, mit "Circular Wait", lauern.
So neuer Thread ist auf, dann such mal danach. Ich konnte keine mehr finden 8-)
-
Ich mag Threading nicht, das ist mir alles zu verwurstet. :-p
Bist wohl Vegetarier wenn Du nichts verwurstetes magst? Also ich mag Threading sehr, da ist alles so schön parallel. :-D
:-P Nein, ich bin überzeugter Fleischesser. Ich finde Threads halt nur verwirrend, weil sie im Gegensatz zu Tasks auch intern voneinander abhängig sind.
Um das umzusetzen müsstest du aber zu jeder Funktion dokumentieren, ob sie ein Lock braucht (was nicht immer vorhersehbar ist) und das darf sich ja dann auch nicht nachträglich ändern. Unschön, aber machbar.
Das sollte man bei einem Projekt, wie einem OS-Kernel, aber immer sauber dokumentieren. Klar macht das Arbeit, aber es ist IMHO nicht "unschön".
Naja, wenn du jetzt eine Funktion irgendwann mal so umstrukturieren musst, dass sie ein Lock verwendet, wo sie vorher keins benötigt hat, dann müsstest du (theoretisch) jede Funktion suchen, die diese geänderte Funktion aufrufen kann und dort die Locks umstrukturieren - oder du verletzt die Policy.
Und ich kann mir schon vorstellen, dass man nachträglich zusätzliches Locking einfügen muss, um z.B. übersehene Raceconditions/Deadlocks zu umgehen...
-
Hallo,
Naja, wenn du jetzt eine Funktion irgendwann mal so umstrukturieren musst, dass sie ein Lock verwendet, wo sie vorher keins benötigt hat, dann müsstest du (theoretisch) jede Funktion suchen, die diese geänderte Funktion aufrufen kann und dort die Locks umstrukturieren
Ja, genau das muss man dann tun. Das bedeutet zwar Arbeit ist aber nicht allzu schwierig. Für das Suchen gibt es schließlich grep.
Und ich kann mir schon vorstellen, dass man nachträglich zusätzliches Locking einfügen muss, um z.B. übersehene Raceconditions/Deadlocks zu umgehen...
Ein Risiko das man mit guter Planung und Strukturierung minimieren kann.
Grüße
Erik
-
Ich habe mal ein wenig gegooglelt. Bin jetzt zwar ein wenig (die Betonung liegt auf wenig :( ) schlauer, aber so richtig was gefunden habe ich nicht.
Also erstmal muss man zw. wait-free und lock-free unterscheiden. Wait-free gibt es so gut wie gar nicht, weil sie performance-mäßig nicht so der Bringer sind (sollen wohl selbst einfach gelockte Sachen schneller sein) und sie haben einen hohen Speicherverbrauch der wohl linear mit der Anzahl der Threads steigt.
Lock-free hingegen ist ne sehr interessante Sache, denn damit gibt es keine Deadlocks mehr und man kann auch Threads/Prozesse beenden die gerade an der Datenstruktur arbeiten ohne das was passiert.
Performancemäßig sind die (richtig programmiert) auch schneller und verbrauchen sogar weniger Speicher (war an nem Bsp von nem MemoryAllocator) als ne schnelle gelockte Variante.
Falls hier irgendjemand ist der mehr darüber weiß, immer her damit.
-
Falls hier irgendjemand ist der mehr darüber weiß, immer her damit.
Ich hatte vor demnächst dazu was ins Wiki zu schreiben und zumindest mal einen lockfreien Stack und eine lockfreie Queue dort (sehr wahrscheinlich nur in Pseudocode) vorstellen.
-
Interessant wäre vorallem wenn mal erklärt wird (so das ich es auch verstehe ;) ) warum solche "lock-free" Algos schneller sind und besser skalieren.
@off-topic
Schon jemand was vom PandaBoard gehört? Da könnte ich dann wirklich mal schwach werden und vllt wird es dann zu Weihnachten nen günstigerer Laptop und dann noch das Board.
-
Ich würde auf dem Board sicherlich nicht nur OS-Dev (wenn überhaupt) machen wollen, sondern mit Linux rumbasteln wollen... Der Grafikchip ist ein PowerVR SGX und die zeigten sich bisher sehr unwillig, Linux-Treiber oder Specs zu veröffentlichen. Es gibt einen Binary-Treiber, aber wie lange (und womit) der funktioniert.
Es wird keine Opensource-Treiber geben und da unter Linux gerade ein Umbruch im Grafiktreiberstack geschieht (KMS, Gallium3D, ...) ist das für mich ein KO-Kriterium. :-(
-
Ich würde auf dem Board sicherlich nicht nur OS-Dev (wenn überhaupt) machen wollen, sondern mit Linux rumbasteln wollen... Der Grafikchip ist ein PowerVR SGX und die zeigten sich bisher sehr unwillig, Linux-Treiber oder Specs zu veröffentlichen. Es gibt einen Binary-Treiber, aber wie lange (und womit) der funktioniert.
Das ist wirklich schade und eigentlich nicht mal richtig nachzu vollziehen. Denn eigentlich sind diese Boards ja für die Community gedacht und bestimmte Hersteller müssen ja an die Specs kommen. Ob die die nicht mal leaken könnten ;)
Gigt es denn überhaupt Grafikchips (3D fähig mit vergleichbarer Performance) wo man die Specs und/oder OpenSource Treiber bekommt?
-
Wie wär's mit ATI und Intel?
-
Wie wär's mit ATI und Intel?
Ich meinte im Zusammenhang mit einem ARM SoC. Da dürfte zumindest Intel rausfallen und auch bei AMD wüsste ich nicht das sie so einen ähnlichen Grafikchip im Angebot haben.
Zumal es schon seinen Grund geben wird warum man bei solchen Sachen gerne PowerVR Chips nimmt.
-
Ah, so genau hab ich nicht gelesen, dass ich gesehen hätte, dass ihr über ARM redet. ;)
Wobei es doch sicher auch ARM-Boards mit PCI-Slots gibt, oder?
-
Wobei es doch sicher auch ARM-Boards mit PCI-Slots gibt, oder?
Nochmal zum mitschreiben ;) es geht um ein ARM SoC, da ist nichts mit PCI-Slots und das ist auch gar nicht gewollt, wir reden hier von einem Board das max. 2W verbraucht (trifft auf das BeagleBoard zu, aber sollte auch beim PandaBoard so sein und das ist ein DualCore)!
-
Kann ich ja nicht wissen, dass du so unflexibel bist. ;) Der Verbrauch sollte bei einem Board, das nur zum Spielen da ist und nicht die ganze Zeit läuft, doch egal sein.
-
Der Verbrauch sollte bei einem Board, das nur zum Spielen da ist und nicht die ganze Zeit läuft, doch egal sein.
Sicher, aber ist ja nicht nur für mich da und es ist eigentlich für irgendwelche mobile Sachen gedacht, aber die Performance sollte doch eigentlich auch für normalen Desktopgebrauch ausreichend sein.
Wie gesagt, sehr interessant das ganze.
Edit::
Zumal ich das Board dann auch dafür nutzen würde, mir Filme auf meinem Monitor anzugucken und meine Alltäglichen Surf-Sachen könnte ich auch darauf machen, also Stromsparen könnte ich/man damit schon, aber damit man den Preis wieder rausholt, müsste das Ding schon so nen PC ersetzen der 24h und ca. 100W zieht. Dann sollte sich das nach nem Jahr rechnen.
-
http://www.phoronix.com/forums/showthread.php?p=107596
Das hab ich auf die Schnelle mal gefunden. (Die Seite [Forum lese ich nicht] kann ich ohnehin empfehlen.)
-
@svenska
Interessant der Thread, aber schon etwas älter und leider bestätigt er nur das was ich schon wusste/vermutet habe :(
Sowas ist natürlich schade, aber uBoot muss doch auch irgendwie etwas auf den Bildschirm bringen und da laufen ja bestimmt keine closed-source Treiber, oder?
-
Mit reinen Opensource-Mitteln kriegst du in der Regel einen Framebuffer (/dev/fb0), manchmal auch geringfügig 2D-beschleunigt. Außerdem ist meist ein Opensource-Treiber für X11 dabei.
Diese können in der Regel kein 3D und kein XvMC (Videodekodierung), manchmal kein Xv (Videodarstellung) und gelegentlich nichtmal XAA oder EXA (2D-Beschleunigung). Multimonitoring betrifft die Chips soweit ich weiß nicht, fehlt aber auch meistens. Über die konkreten Treiber kann ich allerdings nichts sagen.
Allerdings wird wie gesagt derzeit umgebaut, mit Gallium3D werden schöne Sachen möglich... Treiber vorausgesetzt.
-
Hallo,
auf Plattformen außerhalb des x86-PC auf gute (3D-)Grafik zu treffen ist nahezu ausgeschlossen. Entweder hat man was proprietäres (manchmal direkt integriert wie beim OMAP4430 und manchmal als eigenständiger Chip) oder es gibt alle Infos aber das Ding taugt nichts (jedenfalls nicht viel mehr als ein einfacher Framebuffer). Ich hab selber mal nach eigenständigen Grafikchips mit offener Doku und guter Performance gesucht und eigentlich nichts gefunden. Theoretisch sollte es möglich sein eine PC-Grafikkarte in einem nicht x86-System zu betreiben (es gibt z.B. ARM-SoC mit PCI-Express-Root-Ports die man prinzipiell auf einen Slot führen könnte) aber dort hat man normalerweise keine I/O-Ports und auch das BIOS auf der Grafikkarte kann nicht laufen um diese zu initialisieren (hier könnte EFI endlich für Abhilfe sorgen), denn selbst wenn man alle Infos hat wie man einen Grafikchip zum Arbeiten benutzt so fehlt oft die Info zu Inbetriebnahme (das ich dieses Problem mal mit einem AHCI-SATA-Controller von JMicron hatte (für den man mir bzw. meinem Arbeitgeber trotz NDA nicht verraten hat wie man den nun in den AHCI-Modus schaltet) habe ich ja schon mal berichtet).
und bestimmte Hersteller müssen ja an die Specs kommen. Ob die die nicht mal leaken könnten ;)
Diese Hersteller sind damit raus aus dem Geschäft, selbst die Konkurrenz macht mit denen keine Geschäft mehr. Geheimnisse, die dem Enduser nützen würden und eventuell gar den Verkauf ankurbeln könnten, aus zu plaudern ist in der IT-Branche eine Todsünde!
Grüße
Erik
-
Hallo,
in den OMAP-Chips sind soweit ich weiß PowerVR-Steine für 3D drin, ansonsten findet man auch andere 3D-Beschleuniger. Allerdings nicht mit den PC-Lösungen vergleichbar, das ist wahr. Andererseits haben die ARM-Geräte meist nur geringe Auflösungen (320x240 bis 800x480, von Tablets mal abgesehen), da braucht man die Leistung selbst eh nicht.
Durch die Möglichkeit sekundärer PCI-Videokarten sind viele Treiber heutzutage in der Lage, auch ohne Hilfe von BIOS und Video-BIOS die Grafik zu initialisieren (z.B. parst der radeon-Treiber das AtomBIOS selbst), da beim Systemstart nur die primäre Videoschnittstelle initialisiert wird. Wenn Hardware oder Treiber das nicht unterstützen, dann können die Karten nur als Primärkarten laufen (ich weiß es von der S3 Trio64) - auf ARM-Systemen stellt sich die Frage eh nicht.
PowerVR war übrigens mit der Kyro und der Kyro II auch mal im PC-Markt aktiv, aber der Linux-Support ist ähnlich wie der von heute. Hab so ein Teil mal gefunden und ausprobiert... für Kernel 2.4 gibt es Binärtreiber (wenn man sie findet, die Originalseite gibt es nicht mehr), ansonsten garkeinen Support.
Außerdem basieren heute ja so gut wie alle auf dem Markt erhältlichen Grafikkarten auf den Referenzdesigns, die Treiber sind identisch mit neuem Logo und gut ist. Der Hersteller muss keine Informationen über die Chips mehr haben, solange er mit den Daten werben und den Chip einbauen kann.
Schade.
Gruß,
Svenska
-
Hallo,
ich hab mir mal das "System Reference Manual" des PandaBoards durchgelesen und denke das der Energiebedarf wohl so eher bei 4 Watt anzusiedeln ist (für CPU mit allem was drin ist und dem RAM, die ganzen Zusatzchips auf dem Board dürften nicht all zu viel benötigen aber das hängt sehr von deren Benutzung ab).
Dieses Board würde mich interessieren um daraus einen Streaming-Client für nen Fernseher zu machen aber dafür wird man wohl Infos benötigen die mindestens einen NDA erfordern. :(
Schade ist auf jeden Fall das kein echter LAN-Chip drauf ist, dieser USB-LAN-Chip ist eventuell nicht gerade berauschend schnell und dürfte auch einiges an CPU-Last (wegen dem ganzen USB-Kram) erzeugen. Irgendein ordentlicher GBit-LAN-Chip mit richtigem Busmastering wäre mir persönlich deutlich lieber, aber das gibt der OMAP 4 nicht her (für den RAM ist nur er der Master und nen BUS gibt es auch nicht) und integriert ist sowas leider auch nicht.
Das Problem mit den Nicht-PC-Grafikchips ist das diese entweder nur einen simplen Frambuffer anbieten (maximal mit Tripplebuffering) oder eben keine Infos frei verfügbar sind. Einen simplen Framebuffer kann ich in VHDL schneller programmieren als für so einen Chip das Datenblatt zu lesen und ihn ins Platinenlayout ein zu designen. Ich erwarte ja keine 3D-Leistung ich will einfach nur ordentlich und performant einen Desktop mit Fenstern ausgeben können. Dazu gehört für mich z.B. das alle Fensterinhalt bereits im Video-RAM liegen so das ich nur noch die Anzeige-Koordinaten ändern muss wenn der Nutzer ein Fenster verschiebt, es sollen dann auch vorher verdeckte Fenster wieder korrekt angezeigt werden ohne das die CPU auch nur ein Pixel übertragen muss. Toll wäre es auch wenn der Grafikchip sich die Pixel-Daten für die Fenster selber aus dem Hauptspeicher holt, nichts ist für eine aktuelle CPU so frustrierend wie stumpfsinniges Kopieren von Daten (die Hersteller von Ethernet-Controllern haben das bereits erkannt).
So aber das war jetzt wirklich genug Off-Topic in diesem Thread.
@bluecode:
vielleicht schreibst Du Bitte noch ein bisschen On-Topic über die lockfreien Datenstrukturen, würde sicher einige Leute hier interessieren (eventuell kann man das dann auch in einen Wiki-Artikel überführen)
Grüße
Erik
-
Wieder mal nen OnTopic Beitrag.
Da wir ja in dem anderen Thread mal wieder schön streiten ;) bin ich wieder mal auf ein Problem gestoßen was ich nicht so richtig einordnen kann.
Es geht darum das man erstmal nur einen Bereich im virtuellen Adressraum reserviert und diesen erst später mit physischen Speicher hinterlegt (erst wenn das erste mal auf die Page zugefgriffen wird, gilt also auch für Stacks die dynamisch wachsen können).
Jedes Mal wenn ein solcher PageFault aufgetreten ist und man eine Page gemappt hat, muss man ja auch den TLB-Eintrag invalidieren.
Ich behaupte mal dass das zu tierischen Performance Problemen auf SMP Systemen führen kann, weil da jedes Mal jede CPU unterbrochen wird.
Wie seht ihr das?
Eine andere Sache, ich habe mal irgendwo was gelesen das wenn ein PageFault zwecks aus dem Speicher lesen (und die Page halt noch nicht gemappt ist) erstmal nur eine Page die nur "0" enthält mappt und erst wenn dann auch darauf geschrieben wird, wird ne "normale" Page gemappt.
Was ist davon zu halten bzw. wird sowas die Performance nicht nochmehr kaputt machen und wann wird sowas überhaupt gemacht (das erst gelesen und dann geschrieben wird in einer neuen Page)?
-
Das hatte ich im anderen Thread bereits erwähnt:
Pagefaults sind teuer.
Wenn du also das Mapping nicht bereits beim Zuweisen erledigst, dann wird das Programm zwar schnell den Adressraum zugeteilt kriegen, aber bei jedem Zugriff auf diesen "Speicher" einen Pagefault pro Page auslösen. Das kann man mit intelligenten/vorausschauenden Algorithmen abfedern, so man denn möchte (d.h. wenn Pagefaults in Reihe auftreten bereits präventiv mappen) oder man mappt bereits, wenn das Programm den Speicher reserviert.
Letzteres führt zu Speicherverschwendung, wenn die Anwendung diesen Speicher dann nicht nutzt (weil sie nur präventiv "für schlechte Zeiten" etwas bestellt hat). Wobei die Statistik zeigt, dass kleinere Speicherblöcke in der Regel auch direkt benutzt werden, meist aber nur für kurze Zeit vonnöten sind. Darum werden diese meist nicht auf dem Heap alloziiert, sondern auf dem Stack. (Gab mal Streit deswegen, weil MacOSX eher auf dem Heap alloziiert hat als Linux und bei einem Benchmark darum vollkommen versagt hat.)
Das heißt, du brauchst "große" Speicherblöcke nicht direkt mappen, solltest dies bei "kleinen" aber tun, um Pagefaults einzusparen. Oder du alloziierst "kleine" Blöcke woanders. Die Definition von "groß" und "klein" ist Anwendungsabhängig und wird von verschiedenen Betriebssystemen verschieden gehandhabt; allerdings gibt es überall verschiedene Strategien, wenn es performant sein soll.
Was das zweite betrifft, so halte ich es für unsinnig. Wenn du mappst, dann bitte gleich richtig. Außerdem sollte eine Anwendung davon ausgehen, dass frisch alloziierter Speicher nur Unsinn enthält und nichts lesen, was da nicht selbst reingeschrieben wurde. Aus Sicherheitsgründen ist das allerdings sinnvoll, da ein Programm so nicht an im System vorhandene Passwörter etc. herankommen kann; RAM wird in der Regel nicht genullt, bevor er der Anwendung übergeben wird.
Das musst du entscheiden.
Gruß,
Svenska