Thema: SMP und die damit verbundenen Probleme

[FlashBurn]

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.

[kevin]

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.

[erik.vikinger]

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

[FlashBurn]

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 

[Svenska]

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.

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...

[erik.vikinger]

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

[FlashBurn]

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.

[bluecode]

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.

[FlashBurn]

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.

[Svenska]

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.

[FlashBurn]

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?

[kevin]

Wie wär's mit ATI und Intel?

[FlashBurn]

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.

[kevin]

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?

[FlashBurn]

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)!

[kevin]

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.

[FlashBurn]

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.

[Svenska]

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.)

[FlashBurn]

@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?

[Svenska]

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.