Forum: Compiler & IDEs Verfahren zur Multi-Core Synchronisation gesucht


von Klaus (Gast)


Lesenswert?

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.

von Peter (Gast)


Lesenswert?

welchen BS oder kein BS?

von oszi40 (Gast)


Lesenswert?

Wenn alle warten sollen bis der letzte Bummler fertig ist verschenkt man 
Rechenzeit. Daher
http://de.wikipedia.org/wiki/Round_Robin_%28Informatik%29

von Klaus (Gast)


Lesenswert?

Kein BS. Das ganze wird für den Multi-Core Startup Code (in Assembler 
geschrieben) benötigt. Daher ist BS leider keine Option.

von (prx) A. K. (prx)


Lesenswert?

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.

von Klaus (Gast)


Lesenswert?

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.

von MicroSD (Gast)


Lesenswert?

Dann nimm zwei Semaphoren, und verwende diese abwechselnd.

von Marcus H. (mharnisch) Benutzerseite


Lesenswert?

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

von Klaus (Gast)


Lesenswert?

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.

von Marcus H. (mharnisch) Benutzerseite


Lesenswert?

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

von Klaus (Gast)


Lesenswert?

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

von Klaus (Gast)


Lesenswert?

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

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.