|
Anzeige
|
Verfahren zur Multi-Core Synchronisation gesucht
Gast
#2099117
Ich möchte mehrere Cores miteinander synchronisieren. Was mir vorschwebt ist eine Barriere, die alles Cores erreicht haben müssen bevor die Befehlsausführung für alle Cores fortgesetzt wird. Sind noch nicht alle Cores an der Barriere, warten die anderen dort. Leider fällt mir keine schöne Lösung dafür ein. Habt ihr Ideen? Plattform wäre ein ARM mit GCC.
Gast
#2099118
welchen BS oder kein BS?
Gast
#2099124
Wenn alle warten sollen bis der letzte Bummler fertig ist verschenkt man Rechenzeit. Daher http://de.wikipedia.org/wiki/Round_Robin_%28Informatik%29
Gast
#2099128
Kein BS. Das ganze wird für den Multi-Core Startup Code (in Assembler geschrieben) benötigt. Daher ist BS leider keine Option. Wenns nicht taktgenau sein soll, dann ist das eine Abart einer klassischen Semaphore. Der erste kriegt sie (0=>1), die zu spät kommenden inkrementieren sie jeweils einmal und pollen dann solange bis sie frei ist (=0). Der Owner wartet bis alle da sind und löscht sie. Dann gehts für alle weiter. Semas realisiert man auf neueren ARMen mit LDREX/STREX.
Gast
#2102156
A. K. schrieb: > Wenns nicht taktgenau sein soll, dann ist das eine Abart einer > klassischen Semaphore. Der erste kriegt sie (0=>1), die zu spät > kommenden inkrementieren sie jeweils einmal und pollen dann solange bis > sie frei ist (=0). Der Owner wartet bis alle da sind und löscht sie. > Dann gehts für alle weiter. Sowas ähnliches habe ich testweise implementiert. Ein Problem ist mir dabei aufgefallen - keine Ahnung ob nur ein theoretisches: Die Semaphore wird öfter hintereinander eingesetzt. Das könnte bedeuten der Owner gibt die Semaphore frei (=0) und läuft kurz danach wieder in die nächste Semaphore. Sollten bis dahin nicht alle Cores die Warteschleife verlassen haben, würde die Synchronisation außer Tritt geraten.
Gast
#2102371
Dann nimm zwei Semaphoren, und verwende diese abwechselnd. Klaus schrieb: > Kein BS. Das ganze wird für den Multi-Core Startup Code (in Assembler > geschrieben) benötigt. Normalerweise lässt man da doch einen Prozessor die Arbeit tun, währen die anderen mehr oder weniger nichts tun. Unter der vereinfachenden Annahme, dass der Hauptprozessor die meiste Arbeit hat und somit garantiert als letzter fertig wird, reicht ein Wait For Interrupt Befehl (WFI) zur Synchronisation. Der Hauptprozessor erzeugt dann einen Software Generated Interrupt (SGI) und weckt damit die wartenden Prozessoren auf. SEV/WFE haben in dieser Anwendung deadlock-Potential und sollten vermieden werden. Wenn's komplizierter werden soll, kannst Du natürlich eine Semaphore nehmen. Gruß Marcus
Gast
#2103792
Marcus Harnisch schrieb: > Normalerweise lässt man da doch einen Prozessor die Arbeit tun, währen > die anderen mehr oder weniger nichts tun. Genau dafür brauche ich die Synchronisation. Das Problem so wie es sich für mich darstellt ist, dass sowohl globale wie "private" Komponenten initialisiert werden müssen. Globale Komponenten sind von allen Cores zugreifbar (z.B. der Interrupt-Controller), die privaten eben nur von dem jeweiligen Core (z.B. die MMU). Während beispielsweise der "Hauptprozessor" eine globale Komponente initialisiert, sollen die anderen Cores warten bis dies abgeschlossen ist. Ich bin mir nicht sicher, ob das nötig ist, könnte mir aber gut vorstellen "wunderliche Effekte" zu bekommen wenn ein Core den globalen L2 Cache initialisiert während die anderen an ihrer MMU herumkonfigurieren. Klaus schrieb: > Genau dafür brauche ich die Synchronisation. Das Problem so wie es sich > für mich darstellt ist, dass sowohl globale wie "private" Komponenten > initialisiert werden müssen. Richtig. > Globale Komponenten sind von allen Cores zugreifbar (z.B. der > Interrupt-Controller), die privaten eben nur von > dem jeweiligen Core (z.B. die MMU). Während beispielsweise der > "Hauptprozessor" eine globale Komponente initialisiert, sollen die > anderen Cores warten bis dies abgeschlossen ist. CPU1-n: Initialisiert sich selbst und wartet dann auf Interrupt. CPU0: Initialisiert sich selbst und das System. Sendet Interrupt wenn fertig Wenn man eine CPU designiert, die garantiert als letztes fertig wird, dann ist die Synchronisation nicht so umständlich. > Ich bin mir nicht sicher, ob das nötig ist, könnte mir aber gut vorstellen > "wunderliche Effekte" zu bekommen wenn ein Core den globalen L2 Cache > initialisiert während die anderen an ihrer MMU herumkonfigurieren. Solange sie die MMU nicht einschalten, bzw. den Speicher als non-cacheable markieren, sollte auch das kein Problem sein. In einem SMP Verbund wird man typischerweise dieselben page tables verwenden, so dass die MMU Konfiguration ebenfalls von einem einzigen Prozessor übernommen wird. Nur aus Neugier: Um was für einen Core handelt es sich? Gruß Marcus
Gast
#2103852
Marcus Harnisch schrieb: > Nur aus Neugier: Um was für einen Core handelt es sich? Achso hatte ich gar nicht geschrieben: Dual-Core ARM Cortex-A9
Gast
#2103863
Marcus Harnisch schrieb: > CPU1-n: Initialisiert sich selbst und wartet dann auf Interrupt. > CPU0: Initialisiert sich selbst und das System. Sendet Interrupt wenn > fertig > > Wenn man eine CPU designiert, die garantiert als letztes fertig wird, > dann ist die Synchronisation nicht so umständlich. Cleverer Ansatz, scheint ne gute Alternative zu sein Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
