Multicore-Programmierung

Ohne Locks für Multicore-Systeme programmieren

15.09.11 | Autor / Redakteur: David Kalinsky * / Hendrik Härter

Bei der Programmierung paralleler Threads für Multicore Systeme identifizieren Softwareentwickler erst kritische Codeabschnitte und versehen sie mit einem Zugriffsschutz, einem sogenannten Lock.
Bei der Programmierung paralleler Threads für Multicore Systeme identifizieren Softwareentwickler erst kritische Codeabschnitte und versehen sie mit einem Zugriffsschutz, einem sogenannten Lock. ( Intel)

Viele Multicore-SOCs und auch einige Betriebssysteme bieten Möglichkeiten zur lockfreien Programmierung. Die Softwareentwicklung wird dadurch jedoch umständlicher als mit herkömmlichen Methoden.

Wenn sich Programmierer mit Multicore-SOCs und Multicore-Betriebssystemen beschäftigen, stellen sie oft fest, dass sich herkömmliche Multitasking-Designansätze in einer Multicore-Umgebung schwer umsetzen lassen. Mehrfach-Tasks warten oft lange auf gesperrte Locks. Dies beeinträchtigt die Parallelität, verlängert die Latenzzeiten und schmälert die Vorteile der Hardware.

Lockfreie Programmierung ist kein Allheilmittel, doch bei effizienter Anwendung birgt sie erhebliche Performance-Vorteile. Meist wird sie für Programmteile mit komplexen, tief verschachtelten und häufig ausgeführten Schleifen eingesetzt.

Die beste Art, lockfrei zu programmieren, besteht darin, die Software in große und unabhängige Codeblöcke zu unterteilen. Diese Blöcke können dann über lange Zeit parallel ablaufen, meist auf verschiedenen Kernen. Da keine Dateninteraktion stattfindet, wären hier keine Locks erforderlich. Dieses Vorgehen lässt sich jedoch nicht immer umsetzen.

Dateninteraktionen durch Compare-and-Swap steuern

Wenn Dateninteraktion unvermeidlich ist, lassen sich einfachere Interaktionen zwischen parallelen Codeblöcken über die lockfreie CAS-Operation steuern (atomisches Compare And Swap). Diese Operation ist in der Hardware diverser Multicore-SOCs und vieler Betriebssysteme verfügbar. Ihr Einsatz wird anhand mehrerer Beispiele erläutert.

Selbst in Single-CPU-Multitaskingumgebungen sind Lock-Mechanismen problematisch. In Multicore-Umgebungen kommen noch mehr Probleme hinzu, einmal durch den Parallelismus und zum anderen, weil das Task-Scheduling in Multicore-Betriebssystemen ungeordneter abläuft. Die häufigsten Probleme mit diesen Locks sind nachstehend beschrieben.

  • Deadlock

Als Deadlock bezeichnet man eine Situation, in der zwei (oder mehr) Tasks darauf warten, dass jeweils der andere Task eine Ressource freigibt. Da beide Tasks warten, werden keine Ressourcen freigegeben und keine Tasks mehr ausgeführt. In einem Multicore-System können Deadlock-Tasks auch in verschiedenen Kernen auftreten.

  • Lockout

Bei einem Lockout sperrt ein Task ein Lock und nutzt die Ressource, die von dem Lock bewacht wird. Jedoch gibt er anschließend das Lock nicht frei. Einem anderen (oder auch demselben) Task ist es danach nicht mehr möglich, das Lock zu sperren. Versucht ein anderer Task es trotzdem, wird der Applikationscode quasi lahm gelegt

  • Prioritätsinversion

Bei einer Prioritätsinversion hindert ein Task mit niedriger Priorität (nP) einen Task mit hoher Priorität (hP) an der Ausführung. Diese Situation tritt auf, wenn ein nP-Task ein Lock sperrt und einen hp-Task (der vielleicht gleichzeitig auf einem anderen Kern läuft) dasselbe Lock sperren will. Die hp-Task muss so lange warten, bis der np-Task das Lock freigibt. Ein langer Sperr- bzw. Wartevorgang kann die Performance des hp-Tasks massiv beeinträchtigen.

  • Performance-Einbußen

Betriebssysteme weisen den meisten Locks Task-Warteschlangen zu. Bei jeder Operation an einem Lock ist die jeweilige Task-Warteschlange zu behandeln, was oft viel Zeit kostet. Außerdem können Tasks in der Schlange hängen bleiben, wenn sie versuchen, ein Lock zu sperren, das gerade verwendet wird. In einer Multicore-Umgebung müssen oft mehrere Tasks auf mehreren Kernen warten.

Lesen Sie weiter: CAS prüft und aktualisiert kritische Variablen und Pointer

Kommentar zu diesem Artikel abgeben
Wenn ich auf "Artikel als PDF" gehe, kommen die Bilder groß nach dem Artikel (Seiten 5 und 6).  lesen
posted am 20.09.2011 um 08:50 von SLiebing

Ein toller Artikel, den ich mir gerne aufheben möchte. Leider sind die als Erklärung enthaltenen...  lesen
posted am 20.09.2011 um 08:09 von folco


Mitdiskutieren
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 28901070 / Software-Entwurf & Echtzeit-Design)

Embedded Software Engineering Report abonnieren

4 mal jährlich: Die kostenlose Pflichtlektüre für Embedded­-Software- und Systems-Entwickler, von Analyse bis Wartung und Betrieb

* Ich bin mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung und AGB einverstanden.
Spamschutz:
Bitte geben Sie das Ergebnis der Rechenaufgabe (Addition) ein.